
1 0 NOV 2004 



Iwi RQ .. . ; PO T 
i Patentamt 



European 
Patent Office 



Office europeen 
des brevets 



da 



Bescheinigung Certificate 



Attestation 



Die angehefteten Unterla- 
gen stimmen mlt der 
ursprQnglich eingereichten 
Fassung der auf dem nach- 
sten Blatt bezeichneten 
europaischen Patentanmel- 
dung Qberein. 



The attached documents 
are exact copies of the 
European patent application 
described on the following 
page, as originally filed. 



Les documents fixes a 
cette attestation sont 
conformes a la version 
initialement deposee de 
la demande de brevet 
europeen specifiee a la 
page suivante. 



Patentanmeldung Nr. Patent application No. Demande de brevet n° 

03292414.4 ✓ 



PRIORITY 
DOCUMENT 

SUBMITTED OR TRANSMITTED IN 
COMPLIANCE WITH RULE 17.1(a) OR (b) 



Der President des Europaischen Patentamts; 
»m Auftrag 

For the President of the European Patent Office 

Le President de I'Office europeen des brevets 
p.o. 



R C van Dijk 



BEST AVAILABLE COPY 



EP A/EPO/OEB Form 1 01 4. 1 - 02.2000 7001 0 1 4 




Europaisches 
Patentamt 



European 
Patent Office 



Office europeen 
des brevets 



Anmeldung Nr: 

Application no.: 03292414.4 
Demande no: 



Anmeldetag: 



Date of filing: 30.09.03 ^/ 



Date de de*pdt: 



Anmel der/Appl 1 can t( s)/Demandeur( s) : 
Jaluna SA 

6, avenue Gustave Eiffel 
78180 Montigny-le-Bretonneux 
FRANCE 



Bezelchnung der Erf Indung/Tltle of the 1nvent1on/T1 tre de V Invention: 
(Falls die Bezelchnung der Erflndung nlcht angegeben 1st, slehe Beschrelbung. 
If no title 1s shown please refer to the description. 
S1 aucun tltre n'est 1nd1qu<§ se ref erer & la description.) 

Operating systems 

In Anspruch genommene Prlorlat(en) / Priori ty(1es) claimed /Priori t€(s) 
revend1quee( s) 

Staat/Tag/Aktenze1chen/State/Date/F1le no./Pays/Date/Nume>o de depot: 



Internationale Patentkl assl f1 Ration/International Patent Classification/ 
Classification Internationale des brevets: 



Am Anmeldetag benannte Vertrag staa ten/Con tractl ng states designated at date of 
flHng/Etats contractants designees lors du depot: 

AT BE BG CH GY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL 
PT RO SE SI SK TR LI 



G06F9/40 



03292414. 4 
EPA/EPO/0EB Form 1014.2 - 01.2000 



2 



7001014 



OPERATING SYSTEMS 

This invention relates to opjMatirig:: ; sysfc<2nis;; iMbre : partibuJmiy; this 
invention relates to systems, methods and", computer • j^gxjam&-loc--rura^g-l 
multiple operating systems concurrently. 

For some computer programs, it is? critical ttaftitBps in the [imgtiainci. iu» 
performed within defined time periods, or at defined times- Ex^ptes of such 
programs are control programs for operating mnbjiie tetephnj-ie*, of • ftor 
operating private branch exchanges (PfiX's) 6t ceMulaa: basje station^ 
Typically, the program must respond to external events or changes of state in 
a consistent way, at or within a certain time aftter tfte event. This & referred to 
as operating in "real time". 

For many other programs, however/ the time takeh; to >>xeciite : the' 
program is not critical. This applies to; most cm^moix cpiftputer 'programs, 
including spreadsheet program, word prbcessing programs, pay roll ppfejcageyiv 
and general reporting or analysis, programs. On the dthetftyNnd* whjJst the" 
exact time taken by such programs is not critical, in truest cases, nsers svoufd- 
prefer quicker execution where this is possible* 

Applications programs interact with: die pompUttfrs \whic?h they run 
through operating systems. By vfclng the appl;icab'ons;progt^.mroing interface 
(API) of the operating system, the application*, pirogr^n caia be . Written in-ft 
portable fashion, so that it can execute on different cmnputers with different 
hardware resources. Additionally* common operatipg: systems su<sh\ as I Jnuft 
or Windows provide multi-tasking; in Mother --words* tb*y ■ aUbw several 



program to operate concurrently. To ,do Wo, they provide sphpdtilbf; ii\ pthex t 
words, they share the usage of the. resource^ of tibfc c6hijpii?t^-;b^w^eti the 
different programs, allocating time to eicb inaecorda^ 
algorithm. Operating systems* of the this kind «re : very- widely lined; taut they 
generally make no provision for running veal time applications, and they 
therefore are unsuitable for many control or coiimiunicatfo&s :taska.' 

For such tasks, therefore* real time t>peitaHng 'system* hav% heton 
developed; one example is ChorusOS (also know W Choiias) rait, lit' 
derivatives. Chorus is available as -open : so\irc<j sQftvv^ froan: 
http://www.experimentalstuffxon^ 
andJalunaat 
http://www.jaluna.com/ 

It is described in "ChorusOS Features mm* A^Mitectorei ftv^ifew^' 
Francois Armand, Sun Technical Report, August 20(3 U 222p, available- fro/to: • 
http://www.jalunaxom/develope^ ' " • ' 

These, operating systems could also -Vb^wecl to run otbev typfc*> «E 
programs. However, users understandably wish p be'abtfc.to m«i *tfcb vast 
number of "legacy 11 programs, which- are \^ 

systems such as Windows or Linux, withou^havin^ to r^i'ie'Uieisn to: rim m* 
a real time operating system. 

In US 5903752 and US 5721922, an' attempt in made to incorporate k 
real time environment into a non-real time 1 Q^hitmg .vSy^fem: by prcivriding *t 



real time multi-tasking kernel in thedntetiupt nah^twg kjs^nihentjof die-tUmi . 
real time operating system (such as Vvindb'ws). . '., 

It would be possible to. provide :a "du^boot* systfctn, Mtowiftg the usen 

.* . * . . . * * ' . x * '• 

to run either one operating system: or the other;;. but ttoans .are; iliftiiy tus^ 

5 where it would be desirable to be able* to run a "'tegacy"! pro^aim the .s&inb : 
time as running a real time program. For.exainple, 1 toiecDtiintuiucatioris ;\- 
network infrastructure equipment, third getierajioti mobile : phbi^\and txlim. 
advanced phones, and advanced electronic gamSftg ^ equipment way require' 
both realtime applications (e,g, game playing ghip^^^ 

10 applications (game download). 

One approach which has been widely usee?; is ''eronlation". : TypicaHy,: 
an emulator program is written, to run undfcr the* Veal time opsmJhg system, 
which interprets each instruction of a program, wiritten : ^or a gphei&i purpose . 
operating system, arid performs a corresponding: series of ;feir>tiriscti:onS unikr 

15 the real time operating system. However, since: one linstructidni is always 
replaced by many, emulation places . a heavier load .on Ate ^om-pater, : 
results in slower performance. Similar prohtems ari&j \fz6m '/'the ap;pr^*;h 
based on providing a virtual machine (e.g. a J#ya T !^ v^tuWmftqbiait'f), 

A further similar technique is: described hi OS 3995745 (^odaiketx^ 

20 Yodaiken describes a system in which a. moifl : testing real time opeviuing 
system runs a genera! purpose operating s.y.steni as one -.of . its --task*, pre- 
empting it as necessary to perform recti time tasks: 



A more similar approach is that qf ADBOis (Adaptive D^mam 
Environment., for Operating Systems), ci^cttbect fa. i a White: Paper at 
http://opersys.eom/f tp/pub/Adeos/adeosipdf ■ 

ADEOS provides a nanokerael w8ch n intend, amongst nthfce 
things, for running multiple operating systems altfid)igh H appxs&ts only to 
have been implemented with Linux. One. proposed : ds)^ of. AX)J3<?S vVa$ ttf 
allow ADEOS to distribute interrupts to ; . RTA-t . (l^airime A^ptetion 
Interface for Linux) for which see: \ 

http;//www.aero.poliniU^^ 

An object of the present iriveniioit te to piovkte-im in^ov^tf .s.y^te:mi 
method and computer program for running miittipla opening- syidsms : 
simultaneously, even when the systems, are", dem^ieci •M' diffei'eiit p#rp<Sse$i 
In particular, the present invention aims to allow one' of the ajusfa&ng fc : yatia*fts 
(for example, a real time operating systems) to pefforn>;;.\vitfeoxU drstiibbahce, 
and the other (for example, a general pu^os^operaUag .4ystem^ t6 ; pedbrm a&. 
well as possible using the remaining resources of the computer. 

Accordingly, in one aspect, the present iiwWioniprovicie^ a.isysteih i«. 

which multiple operating systems are -sJighjSy modified, 1 and? pix>vided : with * * 

. . . • 'i 

common program which schedules between -.thflira^ifc : which one of the. 
operating systems (the "primary" or ''crnicar operating system). % favoured 
over another (the "secondary*; or non-critical op&ra|jttg:^ysi&m^ Preferably, 
the invention allocates hardware: prefereiifiHliy to. the - critical operating 
system, and it denies the secondary o^ra'tingksysteOT: : or Systems access: which 



would, interfere with that of the critical . open*U^ Pretenvbl^* ? d^. 

present invention uses the critic^ operatic 

resources, even if the access is requested- 1 by the; seeondftjp^ 

However, in no sense is the critical operating systetti ^unhii|g M ttte secondary : 

operating system, as in US 5995745; each. system ijpi^tm tfee others running : : 

i* * • * 

alongside it and only communicates wft& : 'jjifc: /cppimon. projgt^m. 

■ , * *• , • * 

(corresponding to a nanokernel of the: prior art) -Miic;a ^lieirs tfce "access to 
the drivers of the critical operating system. 

Other aspects, embodiments and : p^rteii -j fea&res, Willi 
corresponding advantages, will be apj^ 
claims and drawings: : : . . s 

Embodiments of the invention will: how-&e-.idi^^bed;^by 0% • 
example only, With reference to the aeconipkiym^ cim^ingi;^ in wfciich: 

Figure 1 is a block diagram ^howib^: the* et&£eii$* of . a compter 
system on which the present invention : ciineKecute; : ; 1 . 

Figure 2a. a diagram illustrating the 5 arraagei^^f -software in the 
prior art; and 

* * ■:«.*' ■"*■•* .1 

Figure. 2b is the correspondirigdlggfani iUusjf atra£ (Me suTangement of 
software according to the present.emboeKmenfi ' .: 

Figure 3 is a flow diagram showing the. fctagts .ii^>ctewing tUe .mftwitfe 

of Figure 2b for the computer of Figure : 1; 

- * - • - . *•.••■.'*..•• 

Figure 4 show the components of a hardware* : resource - &patcher. 

forming part of Figure 2b; 



Figure 5 illustrates the program Wed* boat.;?jnd irutiaIfeatio« 
sequence; j 

Figure 6 illustrates the system memory : a*t*tge usei$ ib rile- boat Or 

' . ' - ' : •*.**" 

i ** 1 <" * ** 

initialisation process; . ; . . ' " 

5 Figure 7 illustrates the transition f roin a ^rh;risiry ope^ftg'^te^it&i 

secondary operating system; 

Figure 8 Ulustrates.the transition frame a:jbc<^i^ 
a primary operating system; \ 

Figure 9a. illustrates the eommunicaUbn be^veen apji|icatiaris mrining 
10 on different operating systems according to the invention; • 

Figure 9b illustrates the communication : faetwee^a appiJcatiohs* racr^nttg. 
on different operating systems on. .differed co^ the 

• * : ■ * 

invention; / "J % j 

Figure 10 shows an exampleof the pri^ 

15 virtual address spaces. '.'*!.:' 

Figure 1 1 shows how the memory c&rtextis -i*witel*in| in time; 

Figure 12 illustrates the vfcibie.pai* at .the.hiwofcb'neI : |context; 

Figure 13 illustrates the hiddeh.part of the hi^bkei>iei!conte^t; : 

Figure 14 shows how an initial TSS ft initfeiU^edi Prioil to the; task. ; ' 

20 switching; . j • 

- ; • " : ; .\ ■ j * " . • ■. ■ 

Figure 1 5 shows non zero fields of a -«awAeQ«r -PSS;!; 

• . • i . • • 

Figure id shows typical states of aTSS-si*^; . : * 



Figure 17 shows how segmentation ja£d.«p^^^ 
addressing in the Intel architecture; and 

Figure 18 shows the system-level registersi aS<J 4ata strtteUires mwhiff . 
Intel architecture. 

■ \ : ; 

i ^ * :■ •• • 

Introduction 

System Hardware.. . 

A computer system to which the system'# ttp^ii^ibj'e- 100 ■ce^jprfc}©.!* ^ 
central processing unit (CPU) 102, such as* Periiiiiim^ CPJJ available fioii. 
Intel Corporation, or PowerPC CPU available frbm : fc^tomtir (tpS 
embodiment has been implemented oh both); coupled r^ia a system bus ,i&k 
(comprising control, data and address buses). ;to * readonly ;mejut>i-y 
chip 106; one or more banks of random access mw?ior^ ; (JfcAii^J bhhis (10#V, 
disk controller devices 110 (for example K>B op SCSI eon,tis>J3eti» connected 
to a floppy disk drive, a hard disk drive, and. additional removable inisdii 
drives such as DVD drives); one. or more input/output, pons i"( 1 1:2) (for 
example, one or more USB port controllers, ?wj'd7or parallel poit c^nn-oilcrs ff*. 
connection to printer and so on);ah expansion, bus l l4 ibc : bus ecwiiectSoii ti> 
external or internal peripheral devices (for example .tlie PCl b'^su and other 
system chips 1 16 (for example, graphics aad : sound devices). Examples of 
computers of this type are personal computers (PG>) . and Workstations: 
However, the application of the invention torotber computing devices such as 



mainframes, embedded rnicrocompvjters In .sjfclSM^t *njt «• . 

which case some of the indicated devices stt^^i^^W/cpi^oaere jna^J 
be absent) is also disclosed herein; : . ' . : ' ; 

• • . • : . 1 

Management of Software ; 

Referring to Figure 2a, in use/ the : cbmff&ier IQQ of -.Figufe l; fqns; 
resident programs comprising operating system'^sirriei 20& .^which proyicljss! 
the output routines allowing access by the CP*f: tojlie other decides .show*i in; 
Figure 1); an operating system user ^int^ace or pireseiitation 'layer 204 (such- • 
as X Windows); a middleware layer 206 (ptovimtig Networking «bftware=«nd 
protocols such as, for instance, a. TCP/IP stack) ajriri %pUciatipii£ 208a, 208$, 
which run by making calls to the API routines fdrching the <¥pewtkjg system; 

kernel 202. .:="!. '•' ■ 

The operating, system kernel has a nnmi?e>j<a£ Casks, tn p^rtjctthvr: ■ - i 

- scheduling (i.e., sharing the ! CPtJ and: -oiSfQCiated x^uttje?*' btet^een! 

•-. ; ■'• • •. ':] ' * •' ■ ' 

different applications which ai»runnhig)i .: : . j ' . 

■ memory management (i.e; all6catmg:m^jpryito^a«jh ^ tasfe:and i v^jefee: 
necessary, swapping data and program,* oiitof memory: add'oa t'6;.di*fk : 
drives); •' ': 

» providing a file system; - > 

■ providing access to devices (i^icaily, jpft^^cfiivef&}?. » 
* interrupt handling; "!*-'•■' !:• : 



■ providing an applications programmting • interface enabling, the 

applications to interact with system, rc5O0Kjefrfitt4.ys!ci«. ; 

The kernel may be a so-called "mohoiittiie :{&ruer as fpr U*rix;' : :tn • 
which case the device drivers form part of the kernel itself.. /MternaHyely,. h\ 
may be a "microkerhel" as for Chorus,; in which- casfr tbe device drivers ^re- 
separate of the kernel. 

In use, then, when the computer 100 is started, a. bootstrap. jpn>g«kn 
stored in ROM 106 accesses the disk controlled Idb, to read the. 0ie haiadlii^ 
part of the operating system from permanent! storage -tin disk. into RAjy! t^8, 
then loads the remainder of the operating sysfeiri;.mfc: ijri area of RAM I0&;.: 
The operating system then reads any application ftcnn. the disk! drives-' wta.ihe 
disk controllers 110, allocates space in" RAM iiQS *i'cuc each, mci stores each 
application in its allocated memory space. 

During operation of the applicatiotis, acjheduler port of flic 
operating system divides the use of the CPtJ : between the tfiCrerent' 
applications, allowing each a share of the time on the Rfdc>»sor : ac^rds(ttg. «> a • 
scheduling policy. It also manages use - of 'fe [memory .'resources, : by . 
"swapping out" infrequently used >appi*catfoa$ or<<l^ (ie. 'mmovitfg 
from RAM 108 to free up space, and storing them onii}i.sk). . 

Finally the routines making up the applicat|iOn.s^programrnfag inter faW : 
(API) are called from the applications* to execute TUn'cticms such as. input m\. . 
output, and the interrupt handling routines of the bpomting system respond to 
interrupt and events. ■ _ ' 



Summary of Principles of the Prefepr^id Embod*mejtt ; 

In the preferred embodiment-each operating system Wi 202 <d be 
used on the computer 100 is slightly re-written, and a new low-level program 
400 (termed here the "hardware resource dispatcher"/ and sometimes known 
as a "nanokemel" although it is not the kernel- of an operating; systettVi 
created. The hardware resource dispatcher 400 ii specific' to thijs particular 
type of CPU 102, since it interacts, with the processor. The jvcrsioti* or the , 
operating systems which are modified 201, 202 am also rhps© which ape 
specific to the hardware, for reasons which will become apparent.. • 

The hardware resource dispatcher 400 . is not itself %a oper^um® 
system. It does not interact with the applications pi^Wnsiat aft, and has Very 
limited functionality. Nor is it a virtual machine or emulator; it jequires the 
operating systems to be modified in order to cooperate, even though it leaves ■ 
most of the processing to the operating systems ihtemsdves, ironing; tiwir 
native code on the processor. 
It performs the following basic functions: 

• loading and starting eacli of thfr w&liipfo plating sysicxnfc'a 

■ allocating memory and other system resources to each of tft« operating 
systems; 

■ scheduling the operation of the differem operetsing system* : (U. 
dividing CPU time between .them, And. managing, the .change over 
between them); 



- providing a "virtuaHsecl device" metitbcjl pfl'iM^i' awes* to iiihdsje 
system devices which need- to ; fee shared; >^;the >- opera^f sykfe^ 
("virtualising" the devices); : /f *; ,!• 

■ providing a communications link betwe.envt.H4; seating : .^ysteqis/to 
allow . applications running bn d^bnfat - operaUng. • system^. Uij 
communicate with each other.. ...'.I. 
The operating systems are not treated equity- By the eratf^ifeent: 
Instead, one of the operating systems is selected m . the /critic^!' opeijatiiig.. 
systems (this will be the real time operating sysCeWk anitah? or' e^b : Dihw 
operating system is treated as a -non crinca) ,, lor ^0^^' operating- 
systems (this will be the or each general piirpose- bper^rig sysfom sush is 
Linux). 

When the hardware resource dispatcher :ls designed, jt is pti»videfl{with : 

.• " : 1 ' * * . . • 

a data structure (e.g. a table) listing the. '^4em'. h4>urce*'ai . 

devices and memory), to enable as many systei^ d^ic^ as possible to. b^ 
statically allocated exclusively to one or other of the op^%ing : *ysrems. .. 

For example, a parallel printer port might. be stai^ly^allloeated 3*0 the 
general purpose operating system .202,: which- will oftpa iim iippiicMiiorKi 
which will need to produce printer output. On^he-i^^d- 'in^felJK digf^ 
line adapter port may be permanently allocated -to -the :real time epeitatfng. 
system 201 for communications, Thisr static allocation if devices whenever 
possible means that each operating system : <^o$^ftsi existing drivers to 
access statically allocated devices without needihg;. 1pi cali fife hardware 



resource dispatcher. Thus, there is no : los;s:it>: «fctytip» speed in accessU^-: . 
such devices (as there would be if it acted a vii?ifer jrajaiihSfte or- ^malator)v '• '■ 

In the case of system devices which hiusi be Aarcd^ the ?hai;dw«i« r ; 
resource dispatcher virtuaBses uses of the devices , by the- ; nbji-eritical:- :' 
operating systems, and makes use of the drivers supplied with thVctitittfl: ■• 
operating system to perform the access, tikewis^ fin-interrUpt hwKiling, tW;. 
interrupts pass to the critical operatihg-systein : jhserrapv henttlmg. routinds;: 
which either deal with the interrupt -(if-tt^wiif : :ihtended :*or* thte crl^ij*; 
operating system) or pass it bade throiagh ^-ti^iyf^.'rftsoikrbe *^spaiac?tiejr-«M:'- : 
forwarding to a non critical operating .'system^ :(if ; that was where lit . waV : 

destined). .j . : ; ._' 

On boot, the hardware resource dispat&^j: hi firiit .load$4 aud it iftsmj ; 

; . • '„•.. / ■ '-. . i • . •• • ;. •' ' 

loads each of the operating systems, ta 'apredeterttlintid'sequence, string' wiiji ; 

the critical operating, system, then follow ing .witbj . the- <*r epeh si^emd'ary:- 
operating system in turn. The critical operating i system U? ailoacated -t he- 
resources it requires from the table, and has a f tajxi ineniory . space to ope*ate<: 
in. Then each secondary operating system-hr itifykk. allnfcatedr ^tesoUiiees; I 
and memory space it.requires from the avaikbie r^mainiugreifburces^ 

Thus, according . to the; embodiment. the-'; resumes Used by the? 
operating systems are separated as'.irmch as physlc^y .poteibjte,' by ah^catiag 
each its own memory space, and by : providing aj^Tic allocation ©f devices: 
exclusively to the operating systems; only deyic^s; for which shayiug. is:. 

• * * I • 

* . , • . • J " * ■ *' ' 

essential are shared, \ j ' 



In operation, me hardware, resource drepa&he* scheduler allows the 
critical operating system to operate uoltiL it has cipne}u^e'rt : :ii^ : ta$k4; ahd'thW. 

i * ..* • 
.1 ... 

passes control back to each non criticaiioperating-systeiii in-tunj, anjtil next 
interrupt or event occurs. 

The embodiment thus allows a mnlti operating, system environment; in •• 
which the operation of the critical operating *ys*fc : m is- virtually unchanged, 
(since it uses its original drivers, and- has first access tetany jnfieff^pE -and. 
event handling). The secondary operating systems are able to operate 
efficiently, within the remaining processor time; since Jnjmps't cases they wiij. 
be using their own native drivers, and: will have exclusive access to many of 
the system devices. Finally, the hardware resource d^pateiier itself can be a 
small program, since it handles oniy limited ftmciibas, so iliat system 1 : 
resources are conserved. ; : - 

The preferred embodiment . is also economic in cj^ate .and ;nwinlaio, ~ 
because it involves only limited changes to standard! conxmeicia] operating 
systems which will already have been adapted to the particular wropoler: l Ott : 
Further, since the changes to the ! operating 'i$ystt«ns\ are ^confined • to ^ 
architecture specific files handling matters such as interrupt- ianaiing, and 
configuration at initialising time, whii?b inter&we Wh tliel partietiiiir type- of 
computer 100, and which are unlikely: to change, as lTequently as tbe rest of 
the operating system, mere, may be iitUe ok ito work'to ifo hi adapting, new 
versions of the same operating aystetnjto worlje in a ma)tip>.e operating syVtom: ' 
fashion. , 



Detailed Description of ihe Preferred Embbdiiiaeht ' 

Tti this embodiment, the ! cbmputer tOQ •: waft an Jnte.1 liW • fat-nily.' . 
processor (e.g. a Pentium processor) anda ^o*prola PowerPC • (K^ueed-; 
Instruction Set Computer or "RISC") computer {step 30.2); -. The. crMo$ - 
operating system 201 was the C5 operating' system <the>ali time microkernel; 
of Muna-1, an open-source version Of the ■•fiftfe g^netation-of the CfcioWiCSS! 
system, available for open soiirce;. free, liow^ioad . fron* 
http://www.jaluna.com). 

In step 306, the Chonis<^ operating system pcerbel 2&1 m mpdifiqci fo* : 
operating in multiple operating system mode*, which is treated in the iaime 
way s porting to a new platform (Le. writing anew.Boaiid Support Package to 
allow execution on a new computer with the same: CP$ btu^different system- 
devices). The booting and initialisation .sequences i^e modified id allow -tW- 
real time operating system to be started 1 by. the l^wafeteaouf©?; dispatched : " 
in its allocated memory space, rather tnaii. stamng i.tselfj 'the hardware^ 
probing stage of the initialisation sequence'!* haodifted,;t6-^rev&nt:the critic^* 
operating system from accessing the hardware. fesotu'ces which; are-. 'assigned., 
to other secondary systems. It reads the static hardWare allocation toble from: 
the hardware resource dispatcher to detect the cjevices available to-it. 

Trap calls. 2012 am added to the critical operating' systein, to detect; 
states and request some , actions in Response. • A rtrap^ eal^here-.me^s a- calf 
which causes the processor to savei'the eufrejit context (;e,g.;^ate of registep)' 



and load a new context.- Thus, where virtujxl .niiiitnory adtiitessihg is used, the'' 
address pointers are changed. 

For example, when the real time-operating system 20:1 coaches w end point 
(and ceases to require processor resources); control can he passed; pack to the', 
hardware resource dispatcher, issuing the "idle? -trap call; to fcfeft; % ! . 
secondary operating system. Many processors 'have a "Mlt* 7 instigation; f Ik . 
some cases, only supervisorial code (eig; operating avBtaWs, • nor 
applications) can include such a in^ctu^rlo|i.' * 'fe^rOkls '^vnb^di^eaf, 

the operating systems are rewritten to remove *halt^ mstructfohs imii vepiis^'. 
them with an "idle" routine (e.g ; an= execution ahseid) -which* 'Wh%:.oayed; 
issues the "idle**. trap call. : - : 

Some drivers of the Board Support Pa^o^ ; ate:-sptetot!y ^4i>tei : lid 
assist the hardware resource dispatcher in yirtu^rig the^aredtfq^e^r-. 
secondary operating systems. 

Additional "virtual* drivers' 20*4 ".tee" k^^e^:tp'ttei^w^ ' 
system, appear to provide access to ah input/output f l/Ogf bus, allowing data to . 
be written to the bus. In fact, the virtual W ^iyer 20 lituses m/^iOry'as:;* 
communications medium; it exports some private memory |for input ^ata) aiid 
imports memory exported by other systems (for output data), m thiJ way, the 
operating system 201 (or an application rnnnihg on the .operating system) can 
pass data to another operating system <or application iutming on ib as If -they 
were two operating systems running on. senate- machines connected by a $eai 
I/O bus. 'i 
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The R^ofiEdtiry opemiing system 202 was selected (step 308) as Linux, 
■ haVmgukeiPRelvd-si'pn 2.4.18 <step 308). 

ihvstep 3 113. tfie secondary operating system kernel 202 is modified to 
allow it to fuhctjori • in a multiple operating system environment, which is I 
.5 tseated as a new : hardware architecture. As in step 306, the boot and 
initialisation s&jriences are modified, to allow the secondary operating system 
\p ,be- started by : the hardware resource dispatcher, and to prevent it from 
ae^ssingithe hatrfwate resources assigned to the other systems, as specified 
m. the hardware resource dispatcher table. As in step 306, trap calls 2022 are 
. ""jftf*;. added;, torpass^nh^.to die haidware resource dispatch 

Native- :dfiver»: for ^.shated system devices are replaced by new drivers 
dealing with devices which have been virtualized by the hardware 
fosource- dispatcher .(intetTUpt controller, I/O bus bridges, the system timer 
and the mal time clock). These drivers execute a call to virtual device 
Iiand3m ; 416. of. the hardware resource dispatcher in order to perform some 
. . operations on a respective device of the computer 100. Each such virtual 
device handler 4 ]$ <d the hardware resource dispatcher is paired with a "peer" 
driver roxittfie in $ak critical operating system, which is arranged to directly 
interact with the system device. Thus, a call to a virtual device handler is 
20:. islayedVup to a.peer driver in the critical system for that virtualized device, in 
• • ' 'fetef to moke real device access. As in step 306, read and write drivers 2024 
for tbe victual i/Q bus- are. provided, to allow inter-operating system 
cpmtnarttcatioas. : 

■** *• • 



V. Tlja .inte.rrpp : t;servide; routines of the secondary operating system are 
to^ified, to. provide virtual: inteixupt service routines 2026 each of which 
«spofids;to> j^pejaive; virtual interrupt (in the form of a call issued by an 
Snusntfpt handler routine 412 of the-hardware resource dispatcher), and not to 
WPPM *w real ihtorrupts or events. Routines of the secondary operating 
sy^etp (InciucUng. interrupt service routines) are also modified to remove 
mftsk^g of hMdwaaje interxupts (at least in all excepj critical operations). In 
• }hm.yay f the s^^ir.y. :Q peratmg systems 202, ... are therefore pre-emptable 
oyrthe cr^ticaJ operating syst^iZOl; in other words, the secondary operating 



10 
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system lionise to a virtual interrupt can itself be interrupted by a real 
mtctrupiifw i|\e crtficat -operating system 201 . This typically includes: 
■n •) n^asking^imtiaMidng events (interrupts at-processor level); 

• savlng/re^ 

• ideftli^iag^ 
• • . ' ' ' ■ 

• J. Wkiftg/afiiijiasking interrupts at source level (interrupt controller 

: device's}... 

KeW vkfaol . device, drivers 2028 are added, for accessing the shared 
hardware devices (ihe J/Q bus:bridges, the system console, the system Umer 
m&4»:^]'ifa'& x *M' Thcse <Wv«* execute a call to virtual device 
to^ks-416!Di i -thei hardware resource dispatcher in order to write data to, or 
. re$d;cfetta. fijoife,: ^respective device of the computer 100. 

• ; Tfo effect this, the Linux- kernel 207 is modified in this embodiment by 
adding new Virtual . hardware resource dispatcher architecture sub trees (nk- 
: .IS-. 13U'. and nk-ipe for the 1-3*6 and PowerPC variants) with a small number of 
; ' : '.modified /fifc£: Unchanged files are reused in their existing form. The 
• . original Sh6-erfess ore retained, butnot used. 

; ■ W step 31^;; the hardware resource dispatcher 400 is written. The 
hardware sfesduwse- dispatcher comprises code which provides routines for the 
20. :. ^lQ\ybg#ui^t^ia8Xa»«howa ih Figure 4): : 
: • ; booting; and initialising 1 itself (402); 



: 



■ .Htfxmg j «^s(403).whl«b stores a list of hardware resources (devices 
. • as- p0ct$ t > antf an allocation entry indicating to which operating 
: . system -^achj^source is uniquely assigned; 

■ b^tin^a»4«titialt8ing the critical operating system that completes the 
h^^fcrj^ottropr dispatcher allocation tables (404); 

■ ^ptl»^-ii^d:.j(jd tiding secondary operating systems (406) 
* • ;SlH^^ib6tween.operating systems (408); 

: *- schedtrl|ng between operating systems (410); 
: *. Ji^indliok interrupts (using the real time operating system interrupt 
• , .service jitiiutines, and supplying data where necessary to the virtual 

•iifafrttgjt saryice routines of tbe secondary operating systems) (412); 
■ toddling tjtqtyga&i jfromeach of the operating systems (414); 
••; •••handling, {access to shared devices from the secondary operating 
:. systems (4 1^)'; . 

■■: :b^idljn^i«t©r>b.peiating system communications onthe virtual I/O bus 

ttm. ; ; " : ' 

. In futf-h^^ (described below), it may also provide a system 

pitcher 408 

: ltj.iOT?der. to switch :;from an operating system to another, the operating 
. fevstem.s^ttcher/^iis. arranged to save the "context" - the current values of 
•tbe, set .o| ;; >tatc|y?r&bie.s; such ais register values - of the currently executing 

1 * ' - • 

. * * . i 

».;.. * . . . .... 

•*•*"*'"." " } ' 

: « 
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operating syst^cii^restore the stared context of another operating system; and 
. call- tl-^t p^eriiting systera : to .recommence execution where it left off- 
Where I He p0eessor uses, segments of memory, and virtual or indirect 
. addressing ^teehtiJfluea, the registers or data structures storing the pointers to 
3 . thecuwtftt^ For example, the operating 

systems safch 0{^tidje;to different such memory spaces, defined by the context 
inctudjtig'the jpdhner .values to those spaces. 
\ In detftU*>tjhe pitcher provides: 

; . * explicit s^tcfies =(e.g. trap calls) from the currently running to the next 
to . ■ ■ scheduled operating systems,; when the current becomes idle; and 
. . /. -:* uTiplidt J4W.i*ah^ : ironi' a secondary operating system to the critical 
V ; operating, system/ when a hardware interrupt occurs. 

The «vs(itches:;jnay occur W a trap call or a real or virtual interrupt, as 
-. described be^b^v-. •'• 
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Scheduler 4t0 

Tho scheduler .410 allocates each operating system some of the 
.available preceding: time, by. selecting which secondary operating system (if 

inorc than: on» ib; present) will be switched to next, after exiting another 
. s /•t^erat^i^^bc-.in ttate embodimeiit, each is selected based on fixed priority 

scheduling/ 0the^:ei4bodiments! allowing specification based on time sharing, 
• or gUmnt^dyjiiWii^m percentage of processor time, are also contemplated 
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hereirh J^^ch^^ the critical operating system is preempted 

only when iftjfttj *tii)e state. * 

^ iM^F^^^^^s, the critical operating system may explicitly 
inform the. ^cheuHile* . 410 when it may be pre-empted, so as to allow all 
S secondary. 0|6i^4%. systenis some access to the CPU to perform tasks with 
; higher priory mk * mi inning in critical system. Thus, in one 

example, Ui^ int^fiipt service routines of the critical operating system cannot 
. . be pre-empted,, iaithat the critical operating system can always respond to 

. • external* veojts >or ttnimg signals from the realtime clock, maintaining realtime 

. '■■ '}'. ■ ■■■".: ■■■ : .-. .. ■ . 

. : #j*erauon. 

. Handling vfvliJidi^cd processor exceptions 

. The . hardware resource dispatcher is arranged to. provide mechanisms to 
. : handle pit|cii^; exceptions (e.g. CPU interrupts or co-processor interrupts) 
15... . ;.as follows: .. . .'; 



jtty, tO,=ii3tercept processor : exceptiohs through the critical operating 

• sys%tj; ' 

f: : - s6cot|d!y i ,:tp fost a corresponding virtual exception to one or more 

• * .ftettlf^^ to store that data and, when the 

^cheiittfejt; tHWt ; calls, that secondary operating system, to call the 
;\ ; . : . ^^po^xig. virtual interrupt service routine 2026 in the secondary 



.ppemtiij; system; 



:\ .1 
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• • : thirty/ , Unmask or utmiask. aiiy pending virtual exceptions from within 

sec0^s»y»bperatiiig systems. . 
V iriiutltse4^c^tions:aie typically used for two different purposes; 

• sl FLrsay v #^^atd hardware device interrupts (which are delivered as 
: asgnti^fpug .^acesaor exceptions) to secondary operating systems ; 

. • : Sec^iTif^X(>: utaplemetit inter-operating system cross-interrupts - i.e. 
. ^brj-uplAjgeneaiated by! one system for another interrupts (which are 
. vdelWeitedi ^.syttehrtmous exceptions). 



•The 6per4fe3fJ. the trap call handler will become apparent from the 
V ; ; rolloWing ftk^T^H^ Its primary purpose is to allow the scheduler and 

switcher to. chaise, to another operating system when a first one halts (and 
• ' H^ : ;d<^s. : &^«ire, Cgp. resources). An additional role is to invoke 
: : .. 45 hardwire i^sokircje dispatcher, services such as a system console for use in 

! " * - * * • " * " /""•.**• j " "''*.*. 

'debuggfo»g ! as ^iwiusseA in relation to later embodiments. 



Afr &<Wc3ted above, for each shared device (e.g. interrupt controller, 
bus Bridge^ .'^stem. timer* realtime clock) each operating system provides a 
de^4^^.^g.a^^^-lwel drivers for that device. The realtime 
<jpera^^>ysfeihiprb^des the driver used to actually access the device, and 
the others jp$b'*4dfc vimtai'deyiee drivers. 



ee :6j 8s:bz £B/69/ee 



: • 



22 

The cfcvice handler 416 of the hardware resource dispatcher 

provides, a AMjtapu structure tor each device, for access by all peer device 

• -driers of t^gjgfWe. ., When the device is to be accessed, or has been 
:• ^ssed, the d^e^ers update the data stored in the corresponding data 

■'i ■. -mAt^^^fe^ of fee access. The peer drivers use cross-interrupts 

• • ^^cm^^M}Ao'-stgn^ an. event to notify other peer drivers that that 

. : the data^^p^ Jsasjitst been updated. 

•^.fiv'^^ accessin S interrupt controller devices use the 
vittuolised exertion : ^echanisrns discussed above to handle hardware 

H5 : inJ^rkp?^.as.jfoM.i*jvs: '.. 

> The operating system device driver handles hardware 

. interrttp^! nnct - forwards them as virtualised exceptions to the 
secondaj^i^ex drivers; 
;-• "Che t^iftry operating system enables and disables interrupts by 
usirt^. tfip; -virtualised exception masking and unmasking routines 
discussed aTiiove^ . 

I/O busjSs. and their bridges only have to be shared if the devices 
connected, tty-tha^ i_#e not all allocated to the same operating system. Thus, in 
allocating .deVice» s .to the extent possible, devices connected to the same I/O 
^ a^^V^^Wr^^S system. Where sharing is necessary, 
the- resijupce ;sltocftUp^ table 404 stores descriptor data indicating the 
a.lte(^oi>.olS.^;^8^^ ott. thejbus (address spaces, interrupt Unes and VO 
rfKMOO ta;i^«^«^u)*;ejj^ which resources. 
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fidn ^embodiment 

' j^alfe in R% : 314, thecode for the hardware resource dispatcher and 
o^sratiti$ a^tems ii fcomptlecl as a distributable binary computer program 
• 5 ... pi^ducit.for slip^vieilb the computer 100. 

■ \ A product >Vhich may bp supplied in accordance with an aspect of the 
Wentipa is . a 1 development .environment product comprising a computer 
:'i ip%^^# ^bfes the user to select different operating systems to be 
: usjjd, build and bfelefct different applications for each operating system, embed 
10 "th<* application and operating systems into a deliverable product, and provide 
. - fat booting' of the ^eraEing- system and launch of executable binaries of the 
.• ^ikUtiorufc : ^iUsii is based- on, and similar to, the C5 development 
- -. -c^tjviroTii T3£!x%t^.- : av®il^3tle> from wWw.jaluna.com. 

.;■ Rele#rag tei JKtgUte 5, the boot and initialisation processes according 

*>3uils tfofop&iN^ a 8 feHows. 

• . ,A b^tstt-app^ig program ("trampoline") 4022 stored in the ROM 106 
'is r ex©cu(iid rth&i pjjwer is first supplied, which starts a program 4024 which 
•imstalls thVrtest; fjfi W : hardware resource dispatcher program 400 into 

P**i«S j» an argument a data structure (as described 
beioWX^ates^^^i^Je^ inaage.configuration. • 



' .\ ! : • .24 
• : The ^w4b.r6so^ dispaitcher initialises a serial line which may be 
used for.it; svsiehi-.console. It: then allocates memory space (an operating 
... . • sy^,«ttvljw^jte^> Sot each operating system in . turn, starting with the 
,> «W«|t ^^£&stattt : [ The-h^dwate resource dispatcher therefore acts as 
s 5 '; a second levijb. ystem kernel boot loader. 

"*•••■•**,•**!• 

, B^ch;-^^ ^temJkernel then goes through its own initialisadon 
:.. .. .: : phased sele^g th# resources to be exclusive to that operating system within 
. : , lfe*e remaitti^:, ini. the; resource allocation table 404, and starting its initial 
se^i^^d^^ic^tioris. 
• K>; :fag«i!e : :6: illustrates ah example of a memory address allocation 

. - fartroi|g the .^tem iniage:- A. position within memory is allocated when the 
• t^nmf&f^ and operating systems are compiled. The set of 

% f? s ^ s i in jpe^ory defines the system image, shown in Figure 6. The 
; Kysfem >w*^ jcp^nses* a first bank of memory 602 where the hardware 
'3 . > !!^^ : < i ^f^^^;l««Ja*^- a second bank of memory 604 where' the real 
v r Imie ppet#ii^ system is Jjocated; a third bank of memory 606 where the 
. i : ■ salary, 0^mdt^«ystem is located; and, in this embodiment, a fourth bank 
' of mehiory where the RAM disk containing a. root file system of the 
' '.. ■ s*econ|jaiy op^Ung system: (Linux) is located. 

: ;2Q:, : : ij'T^^stem. image '.is. stored in persistent storage (e.g. read only 
V • - -. melB^ry foriiiy^al jreal thne device such as a mobile telephone or PBX). 
... =• : ytxi .|emai»ii^ b^ks of :memory ..are available to be allocated to each 
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«^enfting-'^5^n ias its ehvironment, within which it can load and run 
: applications.. '} " 

: AMocaU"c*n ^^emwy Operating System Context 

• V^'hilat i : being", booted* each operating system then allocates a 
tK»n^Jetwntai y;piece of memory in order to meet the total size required by its 
own configtirailon. Once allocated to an operating system, banks of memory 
a*; imaged t^irtF the physical memory management scheme of the operating 
System- itself; kfl other memory is ignored by the operating system. 



Virtual Memory Allocation 

: Eacfc o^-aling systeth is allocated separate virtual memory spaces, to 
m;alce stJfc that;Dperating systems cannot interfere with each other or with the 
hardware resource dispatcher. The User address spaces (i.e. ranges) and 
. 15 siipervisov -adck-esa space : (i.e.. range) of each of the operating systems is each 
.allocated- n dierint. memory management unit (MMU) context identifier 
•<ipj;, wMca- afilovy. the differentiation of different virtual memory spaces 
Having overJ^irig addresses. The MMUs context IDs are assigned to each 
operating system at the time it is compiled (step 314 of Figure 3). 
20 ThisU|Ulon. avoids the need to flush translation cashes (TLBs) when 

. : tVje hardware; .i-e^urce . dispatcher switches between different operating 
: glares, wftiefe: wim|W la^-^tipnal time. Instead, the switch over between 
•' . Afferent '.Of^t&*!$mi&M. acroiBplished by storing the MMU context IDs 



: s * • oTjthe cup,^iitly.f ii^otl^i ^perathig system, and recalling the previously stored 
j . > WsW context IDs ctftlje switched two operating system. 

- : . ' . . As i^ifert«>d;:^ove» .the- allocation table 404 indicates which devices 
* : .t . atoca^;-^tiqa<^; to each operating system. In addition, table 404 
U . ;^i^ jwbidi inptM/output resources (Direct Memory Access (DMA) 
• ?" ^vices, ittj^putyuit^rts* mterrapts and so on) are allocated exclusively to 
. j • ^h;. devices, tatisv.ajUowitig a direct use of these resources without any 

■ m : -- > t:dni f jicC typically, f^raiy . devices arc duplicated, so it is possible to reduce 

: ; : " r j^eniial ixinflicts tiubjfeiantiaUy in this way. 

••: • . , :The 'd^^btrtiion is based on the operating system configuration 

; i ] ■ Scheme (fw -exaihple; in the dase of C5, the devices, specified in the device 

; .. ,. ^e)L They, are al^cated to operating systems at boot time, and in order of 

1ft , . Ki5ipifeg, :so <hat the critical operating system has first choice of the available 

. .:; •! in, m» : table ,4^4. and. the secondary operating systems in turn receive 

; to. allocdUoti in what ^remains. As each -operating system initialised, it 

■ : | . i^tec.^s^the=.pi^^fee :6f these devices and uses its native drivers for them 
',.'•''*> ' '. w * tn *»?t ^i*^.fio» from me. hardware resource dispatcher. 



■ ^pPptpt^^xa4»ry Operating System 

[ Accwfttog.'ib-: ;the present embodiments, it is possible to reboot a 
. ^o^d^^^ (for example because of a crash) whilst other 
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operating i^leaira ccuiUnuo to run. Because of the separation of system 
. ; rcs'pgrc?;S,! a4taHb in the : secondary operating system does not interfere with 
: the ongoing .operation-of the critical operating system (or other secondary 
'• , operating iSystenls) and;the rebooting of that secondary operating system does 
5 : not do so ixifeec. . 

Ini;the embodiment, the system "stop" and "start" trap calls to the 
:= teatdwate j;resotiree ; dispatcher assist in shutting down and restarting the 
: swcwiiil^^c^atiing: systems . fom within the critical operating system. 
Additionally, -the. hardware resource dispatcher saves a copy of the original 
KT -. Ryst^ image, ad >oot. time, in . persistent memory within the hardware 
". i^urce .top.atchet located memory. As an example, hot restart in mis 
embojUtntjfo is managed as follows: 

: At;- die tithe, of initially ' booting up, the hardware resource dispatcher 
saves a cofpyof theisecondary operating systems memory image. 
15.. .l^ipjaeitipal operating system includes a software watchdog driver 

• tWme .foB^ *e functioning of the secondary operating 
: systems: example, by setting a timeout and waiting for an event triggered 
: . trya-'pecr toer Riming ip. the secondary operating systems so as to check for 

fhemcontwitfid operation). 
£0. . ' J^iittte. critical operating system detects that the secondary operating 
" ' . s^t^h^^ 1 ^ ^ triggers "stop" and then "start" trap calls (of 

• the seconliffi-y operating system) to the hardware resource dispatcher. 



The hardware resource dispatcher then ^Gpi&^ltffpea copy of j|» 
secondary operating system imaged and wljodtsit.froih- jitetooiy l{» tefcttii ] A 
was found that, .on tests of an embodiment, .the taWfS^ori^ opc*a : tt|)g. 
system could be rebooted within a few. seconds ffdm^dcfcirsg up; • ' j 

In other respects, the hot restart builds upon thutilayaafeible ur'the Chotjus, 
operating system, as described for example in: : . , 

"Fast Error Recovery in CHORUS/OS; .^■rio^teV^bodto^ / 
Abrossimov, F. Hermann. J.C. Hugly, et air Chorus Sysrisrns inc. Tecum^a* 
Report, August 1996, 14p. available from: 

http://www jaiunaxom/developer^ ; . : 

Run-time Operation 

The operation of the embodiment after ins^Katioil and hcibtfng «fi|l 
now be described in greater detail. . 

Having been booted and Wl^^d;.^/^^.^^^: »yW«r«fi| i* . 
running one or more applications 207 (fpr exajhplfr i; UfSP/tP sWk - UQ£|iP 
stands for Universal Datagram ProtoeoJ/mfemet Protocol), and the .secondly . 
operating system is running several . ap^libairons .2#^;:2r>8b Cfor example a 
word processor and a spreadsheet); The .real.; d«toe , operaiing system 
microkernel 201 and the secondary operating systeTii'Tcsejjieii 202 cbmmuniejHe 
with the hardware resource dispatcher U^Ough : ;thcK hardware resoui-ce - 

. - , . i 

dispatcher interface which comprises: . : - : ; < 
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*• . . : • - * • J . 

:' ■ " • r • ..*!.'. : * " 

• a data structure representing the ip«^!:«3^i«»^'<M.-^^^-. . . : « 
state variables which need to be . saved .and Test^cd ^ ^der to to : V 
the operating system), and the-hardware re^sit&ty;, ; •■ • ' ' ; : : ; 

• the set of functions which execute in Jhe.operat^gVsy«tem eav^weist; | • 

5 and \.Y ' 

• .... . , 

• the set of trap call routines which execute .in '^ mVdwaW :^^©- 
dispatcher environment. ' '■> l • 

If neither operating system requires, processor time (for example;. b;dith •: ■ 
have reached "wait" states) then the hardware • resource: dispatcher- m>- : 
10 switches to the critical operating system's idle: tfc&ad,'- W,^hic> it- waits an ■ : 
interrupt or event. Thus, interrupts can :jpTOo«s*«l : ih^di«i%;by- tU . ; 
critical operating system's servicing routines, wftho.^^ : ! 

critical operating system first. .. . . 

At some point, an interrupt or event wul occur;. For .«ix«mple'* a packet ; 
15 may be received at a data port, causing an mteartipt^o ^w-it to W processed . 
by the real time operating systehj executing the UtSWIP istaiik. Altenralhtejv, 
a user may manipulate a keyboard or mouse, :caus^ an .tJ&eirupt tD.opej^te i . 
the GUI of roe second operating system 262 • W.^wiei^^n with the.wwid , ■ 
processing application 208. AUemaftvely,;me : syst^:cloc^may incline tftaf 
20 a predetermined time has elapsed,- and that an- application should commence « 
re-execution, or an operating system Tuhction should:exeiute; . 

The critical operating .systejm seiry^g. foutln© fhen service's • #te • •;■ 

• . . , -• ••■"•'».; ... 

interrupt, as described below, . . . - : . 

. ' • ( • ;* * ' . - 

" • * ' I."' . 



Interrupt and Event Handling \ ) K ' ' 

■ ' ' v Y : : ; • • .- . •' •• " ' 

If not already. in the critteat operating 0stfe4, thelhardwimj reKcliube. 

• : 7 " • •'■ :; •: ' . ; ' '•* *■ ' . ; ::! . 

dispatcher interrupt handler 412; calls tfcj operating dyiit<tors#^|tr^ ? ib 
switch to the critical operating system' and ihe'n >fe jntemipt ta^Ufe- tcMm; 
412 to call an interrupt service routine ih^Vcrit^ 
201. If the interrupt is intended for the critical .operating $yst4ni, either 
because it is Brora a device uniquely assigned joVtfcecrittcat crp^M^jj&fc: 
or because it is from a shared device and has a i^tf.p^^n^d^^ 
the critical operating system ISR ^afces the acd^n- necessary -to; ljan4&--lfee, 
interrupt. If not, control is passed back t©tn£ h&dVire: jesoopce i^aidf^r 



■ 



Critical to ^ndaryiOpen^SiNMs$v»^' .' V { v' 

Referring to Figure 7, for this ekaro^^sy^m 'wc&diSfe* 
thread 702 .of an application 207a irina^^ 



201. 



If. an interrupt^ occurs, a critical ; 0 pe^%isysteia fe%uj* M^cd 
routine 704 performs mterrupt.-servicing. 'oh ! t^^ti6^j^^^^^ 
to the thread 702 and. any others executed ■^tM-^»tf^'^-"^.-*fl^ 
operating system 201. When processing of tft tl^sls complete, ie critical 
operating system has finished execut^;. it? i&d^. W : 1dlf' :M . 
Accordingly the "idle" trap routine iij the cHu^a* !(*pen^.#wk u issues: an 



"idle" trap call to the hardware resource dtj*p«cJ&r ; 40Q. The hardware, 
resource disp&chtfr then executes'a-roufine wti^h" <&ei t&*«^©wiijjr. : 

• If the interrupt handler 412 currently- -hajj Kto?'ed vkm^l. 
interrupts, these are forwarded by the ..wtjwsjigt haodlen 412 .6o thf 
secondary operating systemv 

• The hardware resource dispatcher operating . system scheduler 41$ 
selects the secondary operating systSra 2D2 tpyestecute. the OS' : 
switcher 408 then saves the. current cia^^typ^cWly, : p^ocesser* 
MMU and status registers, instruction and.; sferck pointers) in the 
critical OS context storage area 70& It , thbn- retrieved the stored 
execution context 708 for the secondary operating systeri» 3-02. and 
writes them to the registers concerned.;. : ... 

• If there are virtual interrupts for the •••sectary OS concenpred; the 
interrupt handler 412 calls the relevant inteviupr service routai?- 7.18 
within the secondary operating system-, ivhich 'Mryices she internist' 
and then, on completion, reverts- to the -^ecWtipn iof a : thread 712 of die. 
secondary operating system where it fejfto& ' ; 
If the interrupt handler 412 currently ihjas' wips&oittg interrupts; then 
the hardware resource dispatcher operating switclier 40$: causes tte secondary 
operating system to recommence execution- wg^fc-^Mfc -us**^; ttie stored 
program counter value within the restored ojjerating system context, in this 
case at the thread 712. 



Thus, after the critical operating system 201 fhas r^e^-arixiecf some 

function, (either servicing its own .'applications; or ^^:«eWjees;. : ;qr ;servicijjg- k m 

• i" ■ • •'• ■. • .,' * • 

interrupt intended for another operating 'system^. ..the' haitfWare i&sotfrce 

dispatcher passes control back to the next second aiy: op^ijaiing systanii202. as 
determined by the scheduler 410. . 

Secondary to Critical Operating System Switch tin" ^fe«i>t ' '. 

Referring to Figure 8, the process of ^s^n^ feom tjiig secondary 

operating system to the critical operating system wUt -Aowi be diRclosed. In 

this case, the system is executing a. mread 712 of ai.app^^ 

on the critical operating system 202. 

When a hardware interrupt occurs, the tm^are ^source dispatcher 

starts the OS switcher, to save the secondary op^^^^^-'cirtB^.^^ 
context storage area 708. It then switches to the ^ prii^^per^mgr^sten-, 
201, restoring the values of state variables from the* context s ; tora£e area. 766, 
and calls the interrupt service routine 704' of .the.pi^ry 'operaUttg : ;s^^ . 
201. After, servicing the interrupt, the scheduier' ^ the 'primary, opting, 
system 201 may pass control back from the r&K 704 to. ttny throai 704 which 
was previously executing (or thread to be e^ui^}!.''* :•. • 

When the ISR and ail threads are; processed; |be primary operating 
system 201 passes control back to the hardWare resouree dispatcher, which 
switches from the primary operating system 20t (saving the state variables in 
the context storage 706) and switches to a seieeied isecondafy opiating 



system 201 {retrieving the state variables; &o& 7$&>< 
manner discussed with reference to Figure 3 ah&v|. . % •: ' • • 

. * " 1 * ■ ' * * • ij 
Inter-operating system commuiftcations « ^ 

The virtual bus routine cooperates with; tfcji ^^t[b^"'^jrr^viire*Sl| 
operating system. It emulates, la physicai .crf^wtmg:;tbe Jo^er#«<i| : : 
systems, similar to Compact PCI (cPC&i % _ 

backplane. Each operating system is provvttejd ' wHi* ^dnWyoutine =fb* \M 
virtual bus bridge device on tins virtual 1 bus; a^^Whrt^.tW opers^g sys^ni$ 
and their applications, to communicate by Sony .4&}^T^«oM,..foltf 
transfer to a full IP protocol stack. 

The hardware resource dispatcher yfr^'«i$:is. : ©Hi-" sb&Wd; 

memory and system cross interrupts principle^ tkxf^}^^^''^^ 
detail, the virtual bus routine 4lSjemulates the '^\h»Wm .vyscom which'; 
defines virtual bus bridge shafeu devices, aUiswSm#-<&- export* 
memory across the virtual bus and triggering -of ^pSS4nt%m.plS into other 

operating systems. -.. > •• 

Each virtual bus dxiver/m each see^ create?, 

such a virtual bus bridge in <&e ^jttdv&re :^o^;.d^^\\xa^m 
repository at startup time. By do>ng;so/*;;4p%ts^ji haie^ra >gion.<tf,KS 
private memory, and provides I a way. to i-raiSe, ibte^pts .w.#3ln. : "ite -hc»san« 

i * 1 • ... • 

j • *•: i . • " - 

system. \ \ ' 



Thus, a virtual bus driver of a first .operating, system senk< <tata to a - 
second operating system by: ' ' 

• writing into the memory exported by a> jpeer. vireQ^ bus qfciv^r'of rb>] 
second operating system, and tiien; . . . . . . 

• triggering a cross-interrupt to notify that data are avaijabte loathe pom 
bus driver in the second operating -system. 

In the reverse (incoming) direction, the: y&tuMf bus^'driver.', grt^at^-' 
incoming data up-stream (for use by meappueation ay routine for which. 'it Is . 
intended) when receiving a cross^ihtemmt indicating . that such dateihay^been 
stored in its own exported memory tegion. ; 

Referring to. Figure 9a, an application* 208a u&icfc is to communicate 
with another 208b running on "the; same oi^tifi^sys^m 20£ £aii da sq ! 
through that operating system/ Au appji6atioa.207b wnnipg on <ine- r operating , 
system 201 which is to communicate with onb'aer^'Sbf'r^i^Wii different 
operating system 202 does so by writing data to4he : viuifuk bus tisiikg the APS. 
of its operating system, which uses the virtual bus driv^ rouiine V» jtoa* "fcf'. 
data to the other operating system 202, which propagates.: it from- its- vjitu^i 
bus driver to the application 208b. . 

Referring to Figure 9b, the . changes necc^a^ . to . Emigrate this , 
arrangement to one in which, the first' and second operating .sy^m* ran on . 
different computers 100, lOl are smaU;: it k'niwOy -denary 4rtfee to* 
drivers used by the operating Systems,, so that die* itfse elvers Ho* a real buk 



103 rather than the virtual bus drivers; Tfaeijs&wskis flierefcire. pade: iijo^ ..; 
independent Of the hardware on which iV operated : : , • V. 

Communication across the hardware tesoibfcfc d|8pateber : ^^;« y. 
available to applications, but can also be used hitentally by jibe, operating 
system kernels, so that they can cooperate in the itt^ifexricnta^on./of services • 
distributed among multiple operating systems, «Sni^; J |dist.«b^p^^i^ Of . •;• 
this kind include software watchdog used : Jor Sysib^ hot \res-taarf :(dfecdsse^J-\ 
above), or a distributed network protocol stack,: •' 

Debugging ' Y\ '< "-. : .V * 

In a preferred embodiment, the hatfd\frme.p3!&u^^ 

.... . . - . .;■ . '• . • • .. 

second mode of operation, in whicii it acta- 'as i'dfcbt^ig'ageOT; 

According to this .embodiment, in the; setiorid .mode;,.:m^ thai«wafe - 

*••*(■ **"",* ' 

resource dispatcher can communicate via a :S<^^- carorauipcatib^ W v/hh.; 
debugging software tools running on another machine (the "ftosf machine). ' 

Such debugging tools provide a hiih level ^aptiipal .-user intetfa&ic ; 
(GUI) to remotely control the hardware resource. :d^atche»v .The; fc^d waj« : . 
resource dispatcher virtualised exception mech^sia. is used jo mtercept 
defined exceptions! The user can then coh^« a»4 'controllhow the-hardware 
resource dispatcher behaves; in case of processor exceptions, atid fclao display 
machine and system states, to enabfe oiaghosis^ 'of jiodf * or ^ ste ™ 
or problems. 



••• 36" . ' ; " . ". 

1 • . * 

1 * * '*•";* . • 

The user can select one or;more micli processor c?ccdpti;oris theliasi^ 
for a trap call front an operating system to the*iartlvvat'c:rtisQ^irp6 dispaihV. 
On the basis of the selected exception, when tbe dt' eWh" esjLc^tW|o6e&s, 
during execution, the operating system is. stopped, and ^esjectite* the imk citk 
5 to the hardware resource dispatcher, which then saves the currerct^ontex^ $jjd[ 
enables interaction with the debugging tools on-:thii:host. Tb«us$r ctii^theH 
cause the display of the current states of ftie state: variables (sueh as thesfckk. 
pointers, program and address counters) and/o* * the ^tcnt of selected Bdcte 
of memory. The user can specify either chat ti feiyenitype <sf «xceptiortishoi?l^ 

10 be trapped in a specific operating system to Iw-'itebii^^ox^'lbey'R^W 
be trapped whenever they occur* in : any opening system. JnJ -response; 
trap call is implemented in just one, or in all, opiating systems. . the wsar.iiw 
also specify if a given type of exception is to be normally "'focwawted' i^.fe ; 
system when restarting execution or simply Sgno»«d^ : : 

15 Because the hardware resource dis^ateljeic ^ execates -in lis tmp'- 

environment, it is able to debug much moreJof an.iOpeRitmg.sysfetts than^Ed: 
be done from within that system, importantly, -aid code is sh^d.lbetwieeh ihe. 
hardware resource dispatcher acting- as a debug a^nt^and the sytcm&'ioejng. 
debugged. This allows, for example^ the. debug^ng:of even kernel low-WeJ.. 

20 code such as exception vectors or interrupt service routines. 

Some other aspects of. the; bveratl ihastf$$k) debug^gi ^tUi&ecuire • 
according to this embodiment are shhilar W tqpjje/ for ime^Cnoros ' and fc$ 



debugging systems, described in the document *.<S ^ Digging. Guide" 

" » ,! * * ■ - * * 

published by Jaluna, and available at: : : : 

http:/Aiww.jaluna.cbntfdoc^ •. 

Secure Architecture . .yf* : 

It will be clear that the erabodimerits deM^ftaboye f^rfftwfcaftjft 

for a secure architecture. This is because lte ! ^|^^«ti«ff : ^^^ <m 
which a user will typically run insecure app^e^ns, is insulated franfr 
specified system resources, and accesses thern';#l^'th^gb the. jKardwate 
resource despatcher (and the drivers of the primnryj.c^rafiti g" System)- Tbus,- 
security applications can be run on the primary ijperating systems vyriicll, for 
example, perform encryption/decryption; attow-- aceess ;to. encrypted ; fltee:. 
manage, store and supply passwords and other access /mfor^ioi^; mtMiage 
and log access and reproduction of eopyrighfc : n^#4 Applications : ruo«mg 
on the secondary operating system cannot aceess aj^m-tesowra^ .yhiefa.aws 
not allocated to that operating system, and wh^:i%;ppe&tli^ spst&m run m 
different memory contexts (i.e. use differcn^adf^sittg ^mfcis.'tri -diffident 
spaces) applications running on the se<Mndsu?y ppiiatlng system &a^t fee 
used to interfere with those operating on the.prim#y system -so as tp. weaken 
the security of its operations. 
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■ •* 1 1 . 

This section describes the, inyenfioni.o^ ai^l^veetfe, as an 

example of a Complex Instruction Set Computet (CISC). For ^ b^gtibimd 
understanding of this well known architecture, lfte *^tt|Mi&ig.aibifffcGfiri?o^«.M 
5 by reference: 

Intel Architecture Software Developer's Mimiia^ Volume lit^asic- . 
Architecture (Order Number 2454 70H011) 

Intel Architecture Software Developed slVf»toial." Volume 2: . 
Instruction Set Reference (Order Number 245471 ifftUj ' 
0 Intel Architecture Software Developer' s Manuai, Volume 3~ System 

Programming Guide (Order Number 245472-01 1) 

All are available free of charger from Intel cWpbmtaonv PO :Box 764X, 

Mt Prosper IL €0056-7641 and cmb&downioadedfmm-. 
http://www.intel.coTn ' ':. 

5 Without limitation, some of tHe imiov»tivc ; feature \vfrich 

disclosed herein are as follows: ' ! 

A - The adaptation of the operating •ayst^tt& 16 mphc^spvo4&&mv 

instructions by calls to methods, which use the temimes of thjc bazars. 

resource despatchcr; and particularly but iiot ^cliisiy^iy; 
0 B~ substitution of instructipiis wWcJ^psid idfir wrfce memory 

addressing data siructaressuc^ 

tables), allowing; . 



C - replication of the original memory addressing structures {siich 
as the GDT and IDT tables) to provide proxy daia siniGtwes for operating- : 
systems such as Linux, called by th© niethod&ini5l»^ pi iacfted^rini^the 
replaced processor calls, leaving thejoriginal memory addressing. d«te 
structures for access by the hardwal^ resoorce dcspatcUer; 

D - provision of "public" or f'opetT p^ts brid ''private" or "hidden^ 
parts within the data structures uaed'hy mehai$w»re resource de^nt4ierv ' : 

E - "lazy" transfer of the Floating Pom* Unit (FPUl ibeiw<5e» operating, 
systems, as well as (as is known) between apptjcauumr tin a single operatmi 
system; 

F - Use of task gates to switch cleanly between opening i^etfris, tind; 

G - Use of some specific routines rather than Task gates to switch , 
rapidly between the primary operating system aud thc.hWdJware resource : 
despatchcr without changing memory context; 

H - Preventing the secondary operating system from masking, 
interrupts, except, preferably; . 

i. ♦ ..." 

I - during task switching operations (wjtiSh ;are:QfV^Ty sttftft 
and/or; . 

J - during hardware .resourcd-de^^ 
long duration (such as RS-232 comfcnnic^tto^ w character output); 

K - use of two separate stacfc stroetures f&r context! switching; oris for 
traps and one for asynchronous tasfltisj 



40 . ■ 
L - use of part of the supervisory context of the prfc*$ry operiwiiig - .- 
system to run the hardware resource despatchar. " 

In the following, the hardware resource d^jspatisher. iS 'desOw^d f in& • 
5 non-limiting sense) as a nanokernel/ This Meto>)b4w^WlJ^^liiHi: 
specific aspects of the nanokeroel implementation; in pSttictiar,. piithe 
nanokernel executive which is me comet stone of thtv hanolji«mel- 
environment. 

It describes how the IA-32 Intel processor urchitecuU is used in-order 
10 to implement the nanokernel executive which is capable to *un iriui'i*ple : 

independent operating systems concurrently shariiag Wejjntpj andWajLitig... 
point processor units (CPU and FPU) a* well as.the. nWoryijanaiemem :uaii 
(MMU) across these operating systems; 

* . i . . . 

15 It also describes how the nanokernel cxecutiyt? hanii4* the hardware 

interrupts. In particular, it describes the mechanist used to mderiept and 
forwardhardware interrupts toward the pr'i^opei^g s^tem ^dthe 
software interrupts mechanism provided '^^^a^f^pf^^ systems.' 



20 



Note that we assume that the nandkeriteii^in^ oh ajjugproc&sor 
computer and therefore aspects related to the; sy^hietri^'muWrpioee^or • 
(SMP) architecture is not addressed here; 



Overview 

Virtual Add f^ss Spaces 

On IA-32 Intel architecture natrokemej kway* foots i».* virtual ^os» > 
space, in order words, the MMU is always ona-bled. Oh ti>e dthcriband, the - 
memory, context in which the nanbkernel code is exectMng may vary in tjak 

* . 

*• \1 ♦ ' * ■ * . 

In this description the memory context tenii designates ajv$Ay33 : :" 
address translation tree which root directory table is specified l^thfe CR^- ; 
register. 

Typically, an operating system supporting: Usui modfe^fafco^e^es^-e^ 
multiple memory contexts (one per user process): in difderjto -ffeidHir to-tatitit 
private user virtual address spaces, the kernel chsipgesi the ^ieihc*y content 
each time it switches from one user process to another: Ofctfc&o'te naiad, 
together with the user address spaces, the operating system kernel i|so 
handles the unique supervisor address space wpiicaied-kt^U memory ; . 
contexts. User and supervisor virtual addresses npvep.oyerlap dm JAta^: Intel 
architecture. 



The supervisor address space mappiags way MUM: sialic or ■ - . 
dynamic. The static mapping is created at system, jnidaii^'ation tmie. and it \ 
typically maps (entirely or partially>availabl'ft ^hysic^l. memory.-:Stich . 
mapping also called the one-to-one or kernel vttixpl t^f) mappthgi In 



particular, the BCV mapping usually covers' the -^ernef cejde. dataiahd tiss 
sections. Dynamic mappings ape created at runtime k order to- auiens 
dynamically loaded kernel modules Or dyna^ 
contiguous) memory chunks. • • 

Three kinds of memory corned are tfistihgiiished ^41te.r«an0l«eriae] : 
environment: primary, secondary aind nanokernel. : 

The primary memory context is a ^^^^^.wi^%;iieej, by : - 
the primary kernel. Note that, Vcaw me pri)^ " 
user address spaces, there might be multiple. memory contexts usedfhy the ' 
primary kernel but, as was already menttoned.afeove- the- supervisor add-^s 
space is identical in all such contexts. Becausetbe nanol^mei does netware \ 
about user mappings, the primary memory context is' ttni^up^j' ife 
nanokernel perspective and itjeonsists in static and dynaftSiowp^rv^or : , 
mappings established by the primary kernel, 

. _ . '**" ' *■**, 

* . • • • ' ' • % *. - : . \*\ : * . ■ »■ *. ■ . ■ : '. ... . 

The secondary memory context is! a ktemoiy context cufr^rjy uaeVby 
the secondary kernel. Once more, in case the te^^opfe^iig s^stijn- 
supports user address spaces, there m^tsp-^tipiTOdmoi^^t^iw^^ 
by the secondary kernel but the supervisor ad.dU& spacfe fcwllf' identical in all < 
such contexts. Because the nanokernel is pmyiaw&ie. about the -static. KV . 
mapping established by the secondary kernel. ^secondary memory context- 



is unique from the nanokernel perspective (for giifmi secondary 
it consists of sue* ac«e-to^^ppitt&-It4si^^tfe iioteiKel^o- V- ; 
nanokernel requires accessibility through the staeic l^ 
kernel data used by me nanokernel. Such data structures are- listed iji -further 
sections describing the nanokernel interface to the secondary kernel , :• 

' *" . • • : * f • 

The nanokernel memory contekt is build byi&e -nanokerael i\#c\& Tlhte 
context reproduces all KV mappings established by^e primaify as ^ilja^y 
all secondary kernels. In order to be ableto create such a memoir eonti^Ui the 
nanokernel requires compatibility of all mappings, Two T«Y mappings, art 
compatible if and only if they either do not over! ap or are identical. • , . r : 

Note that when running multiple; identical, secondary kernels,- tnfetis KV 
mappings are naturally identical; and therefore compatible. The problem #^y= . 
however occur when the primacy operating systemfis-differeut from fhe - : 
secondary one. In this case, it might be necessary to modify one of the sys?t(;m 
to obtain the KV mappings compatfbihty. ■ : 

The nanokernel memory context £s mainly used to execute tt*s '{ 
nanokernel code when a secondary kernel is preempted by an mteiwiptj trap or 
exception event handled by me.nanokemeli foe example, in order Uiiperfoim, 
an I/O operation to the nanokernel console. Trie nanokernel memory eontfcfct 
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• . . .!..-■ 

. • * :! . % * . . 

44 [ ' 

is also used as an intermediate iaddress spa^klpwngftpiswil^ fibnvn; 
secondary execution environment to the primary one ^flfvise :v'er'sa ; . '• 



r » 



The nanokerael binary takes a place In ttep$t|rijy:lfr ^jring-aner, ' '. 

the nanokernel code is executing either in the primary jprj in theJn&okemcJ : , * 

memory context. In other words, the nanokernel ;c*>de bix^udng.^p^e in 

the one-to-one mapping defined by the primary kernel ^en the'nftnokernel • . 

preempts the primary kernel, the nanokernel Codei is ejtccuting initie primary : 

memory context. When the nanokernel preenipts it se^ondiWy; kernel; the ■ 

nanokernel code is executing in the rtangjfceratel confonf *Wch replieatk the : 

primary KV mapping. Note that in general mere-ai-e/nj? i^tpicu^a ^vprb^Ty. . 

data used by the nanokernel because the nanqkernefco^eirations called by the . 

primary kernel are executed m the. primary mem^ [ 

primary supervisor address space is directly: C- !•?'..'■••'■ 

• . • " . . •• ■ • " j- • ■ '- '• . " 
accessible. On the other hand, the ^io>erjie:J:^quir«fi : 'iaaiauahy; 

through the static KV mapping to seme primary ^ti^'^itaasM^y fl>©. : . 

nanokernel during the switch to/from a secondary Met sieh! dSata.stwcwms: . '. 

are listed in further sections describing the nanokem^Mterface m the priwwy : ' 
kernel. ' ' .' . : 

Figure 10 shows an example of ttep^ra^ . 
virtual address spaces, * I 

* • - ' \ r • : • 

: "! 'j* * * . • 

} : * • • 

; • * • * I / , 



In this example the physical memory^ is ^^gaby^^ 
primary kernel uses the trivial one^oae (^>^^^:«^ ftbm^ro [.-■ 
(like C5 microkernel) and the secondary kernel u*4 a shitted oieHo^fc ' j 
(KY) mapping starting ftom OxcdDGfOOOi) (Hk^^Mx ^^).-*^ r 
mappings are compatible and the nanokerhel adtlr^$ ^^ ehe#y«<^V= 
memory twice reproducing both pne-torone mappings. j , ' .• • 



Figure 11 shows how the; memory context is : ^t^nngln fame; = =• 
Initially, a secondary operating system is running :jo a ^ond^^mem^- - j" : 
context. At xatime, the current^ondary kernel I^S *P the' n^ofc4i^i» ; '■ 
order to output a character to the nauokemei console. : thU .^p-|vwitch^« 
current memory context to the nahokerriel one. during ihe [tOMp^Lvfc 
nanokernel (running in the nanokerael raenxory content) prints, out a qh#»clk 
to the nanokernel console. At tl time, the nanokefnel ^tums to':the *s*$Aiap 
kernel switching back to the secondary memory eont^t. At <3«*to* an ' , 
interrupt occurs while running the secondary opcratiijg syiitemvrl'he tnr^aipi 
switches the current memory context to th^nanokeTO%btte- and^nvoke^ f&ei 
nanokernel interrupt handler. lit ortler to roi^ 

kernel, the nanokernel switches from the nahokernel ^emory -context to the; 
primary one and invokes the primaiy mterrapt han^ During the' 

interrupt request processing, at time, the primary kernel invoke* the 
nanokernel write method in order to output a m ; e^»ge oa the nibokexwjl 
console. Note that this is an simple inmrect^t which ^oes nbt ; switci&e • 
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memory context and the write operation is. enfir«'ly executed 1$ rtiifc primary 
memory context. 

At tS time, the nanokernel returns -rrom fhe write method to tlie : ••' 
primary kernel which coiitinue the interrupt ^esJiprocessiriritnttt ihe tS . 
time. At this moment, the primary kerne] returns tVom the rotemipti handled 
and the nanokernel switches back to the interrupted secondary operating * 
system in order to continue its execution. Such a switch start* in the primary 
memory context and, going through the intermediate nahokeilaef context, 
finally ends up in the secondary memory ce-niexr at t7 dine. » 



or 



Kannlcirnfel IllVOCat 

The nanokemel is invoked c^«p4#.^^* [■ 
implicitly through an interrapt/exceptjo^hato^i Jn ttfe fortner.«s{se, w4 . : 
say that an operating system kernel invokes tjje nWok^- kiltttotereuse, : 
we say that the nanokemel. preempts an bper^ngisyirterp;. It is ? iraiiojjt«ait;ti - 
underline that the nanokemel is always ravoked jrora ihe privileged fcocle, : \ ■ 
running in the supervisor address space. On t&c: omev hafod, the nwbke^ • ; 
may preempt as the kernel itself as weU as wv&Oe process wmvihg^^ • = ■ < 
kernel control. : ~ 

Once the systemis booted, the natioi^njel is ^jt^a^ed.^.^ tt'4p$ 
execution of the primary and secondary k6rndls;. 0n<^ m^initi.^i?ation 
is done, the nanokemel plays a paWe W ' 
executed in the nanokemel is driven by the p,#mai# #M f&coixiimy ^ernel* 
explicitly invoking the nanokemel (by call .or trap) or by extemulfe pmamA: 
synchronous (i.e., exceptiom) and asynchr^ ; ;' 

.*.!"' • ' ' 

... ' J . • * s ; j • . 

On lX-32 Intel architeciweVmec&a^^ : 
invocation and preemption are Afferent fer p^mW W^on^ai^ operMjhg 1 
systems. In terms of execution environme^ is iiuittvclbs^t Urf 

the primary kernel. It uses the same memory «&Ste& and, scunetinieiii trie', 
same supervisor stack. Thus, the ha^bkerriei^os f olighi^r tlio satn© ^vailar^llty 



as the primary kernel. On the other hand, web is a fidn^beHveea the : 
secondary operating systems and nanokenrei $fty some ipwieditana : . 
against the secondary kernel malfunction^ ttfefe hoover that' such ftpttttijiiQh 
is not absolute and a secondary kernel is still able j*j crash ti^prhnasy J^el 
as weU as the nanokernel. 

• • ' 

Primary Invocation .••'•! •. • . 

The primary kernel invokes meihano^tte^-iy aiimpJein<jj^c? cait : i : . 
Tne memory context is not switched by invdcadoraV! ■ •'*'"•"' . 

„ . '.. ;|;.. ■ '• ■ i. . ; 

Primary Preemption 

The nanokernel preempts the. prfcn^^i^ii^j^mV^^ ^ J [ . 
interrupt gate. The memory context is not's^h^y^^pio^.^^ ^ : . 
native primary supervisor stack is used to handle il% : ;• " 

" • ',*«» 

' " *•.*•-. I : 

**'.**.*;"". ■. " 

The nanokernel preempts the primary ?ofet$ngi$siem-arty 'testa* 
cases. One of them is the device notiavanabfc . 
nanokernel to handle the FPU sharing betwee^e^els in a la^inidn a* \ 
described further in this document. : J 

Secondary Invocation ! . 

A secondary kernel ln^okc» mnol(0«»^r . 

intercepts such a trap by a task gate which swit^.tothe nanokernel meWry 
context and starts the trap task execution'. 
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Secondary Preemption '". 

The nanokernel preemption of j« :-aeea^^,^i|M«f il^^^ 1 * s standi* I ~i • 
to the invocation mechanism and is based divbsk gafcei Whetf" a/sfscaa&uy ■ . ; i* - 
system is preempted by an mt«m^toc*xc^^^'«o^f<!i^^ task-giite! 
5 switches to the nanokernel memory context Snd-sitfro. esecutipn-x^ the ■< : 

! * *i ' .'V . 

corresponding nanokernel task* . ; ; : 
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Kernel Context \ ■ i' 

The nanokemel data can feb split on two e^^ti^y^g^^'^-^fi 
kernel data. The global data keeps the global nanpltetttftrsiiit6'(e^ah.e : : 
nanokemel memory context) while the per-kernel • daiakeepsi ! a - s fee 
associated to a given primary or secondary kernel;. Th» perMkmal data, ferries 
called the kernel context. 

The kernel context consists^; two parts: yfeibfe and. jpin. .The-: ■ i 
visible part is public and takes apart in the nandkeitfel mtdrfaeeJ.Thjii p^tifc 
the kernel context is described in .detail in lusher sections i^laiefiq the.: : i 
nanokemel interface. The hidden part is riot visible to fce*m&-ai^i us«id : ! I 
internally by the nanokemel executive. \ 

Nanokemel Executive Interface 

This chapter describes the nanokernel exc<^Hye tote^"c4e3fpp^d : i& 
the primary and secondary kernels." Such an interf^'c<rasisbs.Hii rfWft sttifM' 
between a kernel and the nanokemel (i.e.; viable kernel'^bttffiW) as -weft as : 
the nanokemel methods. Note mat the nahokernet ; irk<^ace Is kernel role ; 
specific and is (strictly saying) different for tt»'jtin^^'uietirfdtf$»' 
kernels. On the other hand, there is a quite S'tgnificanti inte^eCtion beiweeji' 

these two interfaces which can be described ffidepenkenfly from Hie 
kernel role. 



Visible Kernel Context • V j 

Figure 12 illustrates the visible past ofitfee I^Mjtt ^ntext; . ■ 



All kernel contexts (primary as weair^'4^^f^'.^ , W i *i 111 • 
circular list. The mar field refers to the next ijto^l^Mc^ajA s«ah a psu;; 
Note that, in the visible part of the kernel eontext, fill ieefenCes are mwfe: . 
through physical addresses. A kernel has to convert sticfi f pliysi<Mf Wl^ss: to; 
the virtual one (from the KV mapping) tnordef {o'^ss|^.xe&jeiK3Sd' : . 
object. The picture shows acontiguratidn iwitjijoiitly! riwo^imels: -<p^raa^ad 
secondary. The primary context points to the becontfeity tj*w wtifchf in ftjrp.; :. r . 

■ - ■ • ; 'i *'••-.* ' . ' «* ".*.:* : 

• i • • _ * • -t ' \ • • ' 

points back to the primary context . ; • ; ' -' : 



The pending VEX and envied VEX j^fec^ciijieisj:- ^tjafe^f • » 
tite virtual exceptions. Note thatifcese fcelds are TOftaii^ pii>Tr^ry %. 

context because the primary kernel exceptions a^<$ ^bunla^d by^li'e i. 

nanokeniel . The virtualized exceptions mechanic ^^*ibeel : in j^iiii) 1 * 

. • * -"."*.»"**» •."•*• * : . * i . 

further in this document togetheriwlth the ^conda^ fecial executpri Uttoderr 



The boot info field pointstothe boot paran^tiirsjgi yeii j^ ftlQ^^This.' 
field is read-only. '. = .'■ . 

Note that such a data struciuise is fcernM ^a : theteforqi it-3si^« 

located in the kernel context Among o^ 



structure points to the boot command line specifying tfcfeqrtfaie;. 
parameters, Such parameters are ether given to fjci^t io'ader fe.g.r'GRfjB 
boot loader) or passed through the na^okeWl ewirpmfiettt The :cQ^nmand 
line is kernel specific and it is located indieikeriiel cbbbxt^Well. The ' 
nanokernel parses the initial command line in ^^^"^wl^pedle ! 
command lines containing only parameters related k '' ' i 
kernel. . ; , 

The RAM info field points to the RAM; description tj^T^ field il 
read-only. The RAM description tableis irgl^^Utt^afi^'l^iaJ. 
kernels. It describes how the RAM resource b <^j^4^duW:UrtiA«|- 

" ' " '■ * . • 

* *' • *" " ' 

The dev Info field poind to the list ofmm^m^MKrm^ byttai? 
nanokernel. This field is read-only' for a Secondary feernellan^ cead^write^ 
the primary one. The devices Hs^.^pbirt'^Kr f( ^ shabby .:' 
Each virtual device in the list is represented by a- cla^trncWLpecfed by ■ ' 
the nanokernel. This data structure is typically acce^d by bo^ pbrhary ani 
secondary peer drivers using rules defined by '^wi^i^^^i^.. = 
peer driver plays a server role supporting, the viftua* toe* whelms ! 
secondary peer driver plays a client role using tfteviiriUi device Wead oftta^ 
real one. This list is created (and modifie#l>y ie-p^^ker^eVoiiiy. A ' 
secondary, kernel is only allowed to browse; ims^ '.['{:: . ':. 



The pending XIRQ field specifies pending gftaj' inlemtp^rThis field j 
is not used by the nanokeniel itself. lt ishosted by. tJiejpiJtext Siruta^in, . • 
order to assist to the primary and secondary kan^tejrije cross in^ii?apt$ . 
exchange. There is only one exception dedicated to tito cross intett'Up?. 
delivery. The pending XIRQ field allows to exte^the'iura^er. of cross 
interrupts up to 32 (one bit per cross interrupt source):; A c^ ; ia»«ijit%» : • 
set by the source kernel (i.e., the kernel which semis ^s inftewap^'and^ is. 
reset by the destination kerne! (i.e., the kernel which reives the cross 
interrupt). . ' '.' ; 

The ID field contains a unique:kernel i4^ufe*V TW8.tield#.i^^;Only^ 
Identifier 0 is assigned to the nanokernel ttseirattCide^tifier I is ^ ^dgriedWO -• 
the primary kernel. The kernel identifier designateij'iie icemet.in: . 
nanokemelmterface.Forexamplei the keiinei rd^fii^Ss u^d.tb irt^ 
resources assigned to a given kernel (e.g., memMM# : i&%nWiri the RAM: . : : . 
description table). : 

The mwungfield is a flag specifying ^^ Oie^^Ist^rnnnJirif or :•; 
halted. This field is read only. The nandkerhel. ^«{^^B^^di»1a>^l#>g. 
the kernel and clears itohce the kernel is halted. Whew a kernel &«at*icMi0, 
the running flag is first cleared and then; sei My'k^el.Ls ftbie 1 toferciwse-ithe 
circular list of kernel contexts and to aiaalyifce Kenning -Bag in. 6*d$sr wrjCfld 
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out all running peer kernels. Note ttmt the rurinipg$ii& is-^ay».;W forth*, 
primary kernel. ; 

• • • ! " • * 

The final part of the visible fcetnel coa^tle r&le speciCici . 

The primary context specifies Sddressejf^f&e nanokfcrnel interface 
methods. The primary kernel uses these 4ddre$s;e&^ the ;. 

nanokemel through an indirect function .caflv:^ set . 

up by the nanokemel and they hwstfcot be njoditfedpy the^Wwy keniei. 
10 The nanokemel interface methods are described mtteiail m fee-next section- 



The secondary kernel uses the trap rafceh^mito htebfcfc die 
nanokemel rather than an indirect call. So, addresses of the'na^c*n'e.i : 
interface methods are not present in the secondary cbtttex.t. : ^tsteadV,thc 
secondary context has a secondary TS bit field whleli keep* *h« tS hit state 'of 
the CRO register. Such a software image of the-TS bit may Re used by the. 
secondary kernel in order to manage the I^U p^ree in{a;ia4 way a* 
described in detail further hi this document. • if ' 
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TVfftnnl^emel Methods 

The nanokernel provides two:g^ 
operations and the executive operations. The console ij6 fi^iip MteWs a ; V . 
kernel to send/receive characters to/from the nanokernel console serial line,: . . 
This document does not specially address the ebmoJe VO ttleihcid* Mjfrich -are ; 
more or less generic but rather it is focused oh die executive: rne8»odfi whi'dt; ' 
are IA-32 Intel architecture specific : a ■ ; ' 

Basically, the nanokeniel environment re^^ . 

processor instructions with the nanokernel mjettibids. $iicl^sul»tkutec| ; : . 

instructions typically load or store some lA^a^rttei prQcossoj reg&ta- • 

©Global Descriptor Table Agister (^T&} : " .:: ; •*. 

©Interrupt Descriptor Table Register (DDTR) .; 

©Task Register (TR): : - 
Load/Store GDT Register (I^T/SGM* 

Instead of loading/storing dhsectiy tOitro^'tlib^DT ir^gistk: via thefA--^ : 

32 Igdt/sgdt instructions, in the nanokernel etiyNihmeni, a kernel Mm to . ■ . 

* • * 

invoke the Igdt/sgdt nanokernel. methods to do ".So. These methods' similar 
for the primary and secondary kernels except that they are. wditeet efclte for 
the primary kernel and traps for the seecrod^ ones: .; 



Similar to the processor kif/tructii)ns, the M^g'^^pl^ellTOiErtihod^: 
take only one-parameter specifying a 6-byte mi^\tea®t&k t\U&timmiths 
native table base address (a virtual address) and She; «;a ; fivfexabie iifeft |siice of l : 
table in bytes). It is important to underline that.the ^ativerGK3T rowst^ways 
be located within the KV mapping (even for t^erp^mjcwy l?ern^f); 

; .i ; ! ' 

The nanokernel manages a per r fcei*nel gibb<^dWdpior4^i This; 
(real) table resides in the hidden part of pie kernel iite^ishoSvi'iqafEigi:^. 
13. Together with the real GDT, the n^okenjieKkel^ pointer to the native : 
GDT which is given to the nanokernel via^ihe Igdt mewed/ The pMokernel : : 
initializes the real GDT from the nativeone by copying the segraeitt; 
descriptors. Note however that a part ofthere^ ; GDT,i& resbrvedf^ M 
nanokernel segments. The nanokernel haiaUeMibii^g *pec«f£ajg &• ."' 
mapping between the native and re al tables; Ffbr^b entry in the'ireaJ 1 table': '•' . 
the mapping specifies whether the entry is; usedf oii a ianokernet segment; of: : 
it is inherited from the native table and mferefbre contains l a copy "of fee. ■* 
corresponding kernel segment. The real; entries . nsJd for the nanokernel 
segments are not updated by the Igdt method. . : V -. 

The nanokernel segments?^ laeat<^M . 
default size is 256 entries. When porting a keri)# .to .die nanokernel 
architecture, an overlap between the kemel.and;nanbkemel ^gmfen^ sto^Jd 



„ r 

t - 



; 57 - 

be avoided by :either ; rc-arranging kernel segpieftts :.v^^iJfe »^v<> tafeiB 
(moving them tothe.begitining 6f : i£fe.tame>:or,^ 

Load/Store IDT ^glster^ ^ ; 

5 Instead of loading/storing directly tb/ifcoift ihe t^ttgister ^a-^:^ ;! 

32 /«/f/5/Jr instructions, in the nat$i«^ v en^^ Mum involaf 

the lidt/sidt nanokernel methods to do so; TheWineai^fife f iinij^&r me. . .. 
primary and secondary kernels except that they are indnect'calis for life ' : = 
primary kernel and traps for the secondary ones, • .: 

10 : '[■'%. ; * • ■ :! 

Similar, to the processor insthictions/th^ 
take only one parameter specifying: a 6-byte me^t^l^^an tows&Btoto& 
native table base address (a virtual address) and the native table Ktttfr &i?e a&* . 

table in bytes). It. is important to underline thftt the 'wdffi&y&t must: oiwaySs bey 

• . ..- , ; .• ': ■ •vvi;.- •'. " • • -" 

15 located within the KV mapping (even for the primary . ;kj?3cnel);. : • .; 

The nanokernel manages apeir^em©!-^^ tsa>ie>. TbJs-..j. 

(real) table resides in the bidden part of me.kf*ne.i cfjo^i $H'o#noh ! Pigute . : : 
13. Together with the real IDT, the nanokernel keeps 4 jpoietf er x6 this aafivp ; 

. :"***.■ * * . . • * 

20 IDT which is given to the nanokernel via lhie : Mdl: me(iiQ^rT^e : nanoJ|;epiel 

initializes the real IDT from the native one by cipyMgi .tite gate deertariptofs. ; 
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Note that the nanokernel eah : mstell.i:t«r=Ovvrft l^tek .in t|us jj^Vtik>ie>&ii • 
order to intercept an exception. Forrexainpie^t^ th& '•;«■■ 

device not available exception (#lKfoin oikier^dimJtn^ • 
lazy fashion. So, similar to GDT; the nanokemej ^handle? a bit^tiin^ 
5 specifying a mapping between the native and real j^es;' Am each entryiift'ajl 
real table, the mapping specifies whether the eofry^f } n^lc&frftfc a. 
nanokernel gate, or it is mherited from the. native table and therefore contain^:' <■ 
a copy of the corresponding kernel gate'*- The* real ^•^trfefe^nsfSaJ^d Ifte j » 
nanokernel gates are not updated by the: lidt me:$q{ii 

10 ' ' • • ■ '• '• ••' . ■ ";' . I- 

The real table size must be equal -to-or ^^^tlum^-^i^^ci' V . , J . 
size. If this requirement is not meet when porting ffike^. to^in^ka^tei [:'■■) 
architecture, either the real tablets has to '(Mj^^^liol^-^v^uiMe : ' . 
size has to be reduced. • 
IS Load Task Register (LTR) ■'■'[ \ \ "k .J 

Instead of loading directly .to the taifc &&^.ifte^'1&$2i $ *\. f :. . 
instruction, in the nanokernel envhTahmeht- -a kernel 'jjfo&p Sn.yojfe.fee lit '" 
nanokernel method to do so. This method is aimUte fcme^rinjary ; aid. 
secondary kernels, except that it is an indirect call fer th^ p»lfrvar,y \somel awl p, . 

20 trap for the secondary ones. '" ' - 

'.. [ '■■ •[ ' ; ' .V; ' •; ;. 

.*.'•. * » ; ' • * , . * • " : ' . ' • 

Simitar to the processor instruction^^ i\{ 
only one parameter specifying augment s$bs^f ^'g^Vto^ t^k state ' 



segment (TSS). It is important to underline, thitt the; TSS' p^^a ©Ui : fcly ,rti'<5 ■ 
segment selector must be always located within m%^g-(*ve«f(sr;m^ 
primary kernel). ; ' ;' '• 

Idle ! ; . ' " '• 

The nanokernel provides an. idle metbocl ivliicn- lias i6 fee oalleti by * 
kernel within an idle loop. The iaieraef^^^«l^^tt^^:^32l^;i& 
instruction and it informs the nanokernel that-the caltog.ke^n^I- has. nothing j&: 
do until the next interrupt. This method is sitaUatf fax i!he p&pi^-y and- : 
secondary kernels except that it is an indirectlcjUifor ;tj*e pci^y kernel^ asid a 
trap for the secondary ones. '' : - '•. . 

The idle method invocation results' Mia s^tein'switeh ti> tine t&xt.i^i&ij 
to run secondary kernel (if any) or in the returefrorii prjmiu-y idle; twsthod 
when all secondary kernels are idle. The idle methbd.^ no;pa»-amfeter. ; 

■ The primary idle method should be calle^i'wifena^ted prqe«HK»« .. 
interrupts and it always returns to mecaller with dialed, processor ^ int^miptis; 
So, once returned from the nanokernel adle^e^^fe primary &ufeel> tfhlf. 
to directly execute the IA-32 sti instractioh^ilo^eiijhy the lA!-32.>#/ '■" ■ 
instruction in. order to suspend the processor '^|^4^^^)ApWkr 

•*.-** • * • • * . . . 

*. • • * * * , - ■ • 

The secondary idle trap can be called' either ensibied. pr disabled \ 
(software) interrupts arid it always returns toijrjie; e^^wi^enafete4 ' 



interrupts. In.fact, the secondary idk ; trap-imp'Jte&# enables Interrupts and it -= 
returns to the caller once an infeiTupfchas been ^Jivereil. to this tenet us a 
virtual exception (VEX). 

Restart • :'.'v. : ■■ •'. 

The nanokernel provides a resW.n^fhod^hich can bulled asi £y 
the primary as well as by a secondary kernel fa otder "^Vestairti»^ohd&ry : ?' 
kernel. This method is similar for the primaryland sa\ : )ndarykem<4s cxc&pt^ 
that it is an indirect call for the primary kernel 9i&.k*XQ&f&*u$mdiqi . 
ones. ' . • 

The method parameter specifies idehtilWojf the kentelWrjg:re*^f^; 
The nanokernel stops the ken^l execution, re?tD>>!> ^ kernel' iii^;fro^rt«rJ 
copy and finally starts the kernel ex&htion atithermUial enwy pojnt. 

Secondary Reboot 

The reboot trap is provided b£ the na^k^nel.to * ^ecohd^ kaiihe'l, . • 
Such a trap is called by a secondary kernel w^n,iris i&booting: Tfiis trap is 
equivalent to the restart trap called on.: the kernel itself/ ■ : ■:■ 
Secondary Halt . 
The halt trap is provided by tab nanokem& : t6 a secondary kernel:. ■■ - 
Such a trap is called by a secondary ken^l : whei^t >sl|»a^a< T^-n^okemel. 
puts the caller kernel into a hbn running state in order to.-avoid^bi&kerh^ . 
being switched in by the hanbke'rnel/schedulfcr: : ; ; 
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; 6i •■• 

A stopped kernel can be scarfed again by t he re^&it^anoke^eliiiet^od ; 
described above. '! ' • •. 

J " s . • " 

Primary Exemtitm E^roifenent > • 

environment. The nanokernel rapieijoent^ipn on fcV32 Intel processor tries: 
minimize : 



Because the primary operating systein is typically a teal-time operating 
system, it is important to keep the penary kervielhehavibir^nchkaged - evesnif 
other (secondary) operating systems! are ruaaiiig;«m tfjs'ston© . ; 

processor. I . . i 



. .. • A 



\ 



. ' ! »■ 
1 • 

| : 



Initialization /../». 

The nanokemel is started firiitby the boot loader iwitti clisafoied MMf,. 
i.e., in the physical space. Basically,! the nan.okeiW iiita^tibii cade jnttaJte' 
the primary memory bank (containing the-jprimaiiy j&t$&-i6$duiin»- 
sections) in the physical memory and. juirip^ tq. the prtrtiiaiy entry point. 

Before jumping to the primary kerfiei; the nancr&ernet initial JJre-, ' 
primary kernel context, and in particular, Uie real GDT kndiPT to an mm ■ 
state. 

: • • * i ► • 

* " '*"""» * • " ' x 

■ . * * » ! "• • 

The initial primary GDT ha*} only. two v.f id envies specifying the 
nanokernel code and data segments." The sigteetors used-ft*. tfeerii#c<ftfc : 
and data segments are fixed by the nanokemel infeEfac^(o ; Q^iOatid 0x1$ 
respectively. So, when porting a kernel to the I^2-.nWo<tei^i'aK^ectttt^' • 
the above code and data selectors J&ve to be used. : 

All gates in the initial primary IDT as welV-as'ti)e;task register. ai^. ' 
invalid (zeroed). '*. 

The nanokemel iiu^ahz^p^ 
nanokemel staeklocated in the date-section;. . meix jumping tpjbe primary 
kernel, this stack is still valid. Despite of tfet,- the prims^y kernel should 



switch to its own stack as soon- as possible and shoW d;.never -Crse-this 
nanokernel stack in the future. Thenanokertfel: stable leased tfotmly at; : : «" 
initialization phase but also at run time in or iter to kaaitte fiecoridary 
invocations and preemptions as described in! the : ii«xr!clbiapififf. • .' 

When jumping to the primary kernel; tbi; ^ie^.fe^s^ic points to :\M v 
kernel context and the eflags register is deaiedV Sp\ : processor Vntermpts 4rfe : 
disabled at the beginning of the primary initiai^jaf^ ^hase. tfaftimwf . j I 
kernel usually enables interrupts =onee a ; critical :initia^tttibii.pj3a<fe isdorigl 

During the initialization phase, the primary kerbel itj^ie^iy hiva&$ " 
the nanokernel methods in orderto setupthe Q&l'r W ittft task registers-: 

. . ... „• , '. ., • : •: ■•. : • \ " ■;. •• •; 

Finally the primary kernel enters in the idle loop and iijvo^ fe itaupkeiasei 
idle method. ; ; 

When.the idle method is cailed^Fi^trtWv. tfee nkndke^fe^.d^wd^: 
that the primary kernel has fully initialised its; execiftfeo. c^v^rtfecnt :-«tu}3? :: 
proceeds to the post initialization phase. : : V: 

In such a post initialization phase, the hanokelTtel builds the . 
nanokernel memory context and-initializes the secondary kernel contcw«,ffij 
described in the next chapter-Note that the naabkernei: memory context ; 
creation is deferred until fee post initiali«sition:phfise because & requires • : 



allocation of physical memory for building fcb.etomsj&toh ^fbufctije . ' 
available memory resource is dkcovered-.^^si«fe4 by l^pebfj^tSu^ 
initialization code. Once the postinitiali^tibn^ * : ; 
the scheduler in order to either switch to .a .ready to tun s^ni^ry^irifel^^ • : 
return from the primary idle method if all secondary kernels titoii UiH. ■ ■ ' 



The nanoicernel requires the primary kernel to ." v 

shared data structures: the RAM descriptor ahd tha viffeal'.defe^:ii^,:Ski^ 
an initialization has to be done before the idteljBWh^isialiejlV Thlsf ! ! 
requirement is natural because beyond this moment a &^&^kei£e| eau.. • 
access the globally shared data structures. . , 



, i • 



In particular, the primary kernel is irj a&g* id ;ctet©ct tife ' *\ 1 

memory available on the board and fore^i^ 
in the RAM descriptor. ! . I :l ■ 

• *; . ' : ' * ' * . ♦ * 

According to the: primary Board Su^po^ pac^gej cBsii}, ttidlprlmuir ; 
kernel should start nanokernel a\vaire driver* wh>h;,ii| Su^. s&id^lopuIiMie ; \ 
the virtual devices list. Such virtoal devices .arp^vi^ 
and therefore they should be : created before the %rsr.secondiS^ kerri^J is ; 
started. . . " * - • . 



Intercepted Exceptions, 

Basically, the nanokemej do€«.^inittr^t^cep«iQ^:^*Btt occur 
when the primary, operating system is.ranriing .dn^prpcesaorf A^l ; 
programming exceptions, traps ana interrupts W h«aidted by n&i*©- jwi^airyV 
handlers. The primary low-level handlers cto nbi nee<ji. to be 4afett&d : w*iefv : •' • 
porting to the IA-52 Intel nahokerael aichitectiire- \ v i 4 ; 

An exception from the. above ittleiis'sm^inrtges^^^^ 1 ^ ; 
to the FPU emulation: . - .' : • 

©the invalid opcode excepriow^JDH i " •' 

©the device not available (exception 0*§tSl^»<JtO - : ; . . : , ' 
The FPU emulation feature is used'by'?ttte n«fe(»lt!einei^.i^J«ii^t ; k 
lazy mechanism of FPU sharing as described^ ; . : 

Another special case is a 1 debug; agent wfttch \&»m he f*ib«?cld«d in lie 
nanokernel in order to provide a hoWt based rernate syst^n digging cfftbe'^ 
primary operating system. In this case, the debug itge^ usua&y; mmrcepttf 
some synchronous exceptions. related either to detougyfeataresKe.g.,, single 
instruction trace) or to program errors (e.g., psigafai^) fcs described above in 
more general terms. 



Forwarded Interrupts , ; I 

When.an interrupt occur* whuVa jsecohdarjj operating, systejm is 
running on the processor, the interrupt isfbittartiA&titf the primary :opeiiatiii;g : 
system. Such an interrupt forwarding, process" goes through the ifcrfWiftjj : 
major steps: 3 •;. • 

©the interrupt is intercept^ By the nttiuikemeJ;-::' : ! ! 
©execution of the preempted ^eeoiido^ Icernbi is suspended ; " • 

and .-V .:. • : ": i: 

the nanokernel switches to thp.pri)ma>y.cx^cuf&in cnvi^^t; ' . • • j 
©the nanokernel triggers the bpn«s-p^naMj4;&^^;^ih^ •'. | 

.• ' • ' ' ■ ■. ; ■ .' ■' ■ ~.l> 

primary kernel using an fifc instruction- . - . •-: ■■]''.' • • ? 

' ' ■ '■ ' ■ '' ■' ■ -. : •'.■•"!: : '■ '. I 
In such a way the corn^ponding-prinwy ^^^^^^^^^a^t-M 
invoiced (in the primary execution envirohmejit) iv&cfcr. i©^ roce$ ithe . •' : ; ; 
interrupt. Once the interrupt is pjracjss^ri^thteprit^ 
nanokernel executing an . /mmstacdqiM- ■■■.]■/'..... :':■■■[ \: : 

After returning from the pdtniary..|»iewu^[ft4aier. tl^-naookirnei , .1 
calls the scheduler in order to delernnne; ihe' aexf secondary; operating system I 
to run. Note that the preempted secondary sytfni^riyld «ot:^sc^»fcy be 
continued after interrupt. Another 1 (higheii p^ri^y Wondary sjM«U may " • & 
become ready to run because of the interrupt; 



Secondary Execution finvirorinttiat 

Basically, the secondaiy^kerhM^ 
to the native one except for the.tatea^ Tf ^h^a&^o^ 1 

environment modifies the native mechanisita of fe^.4:ittei*irp^i 'ifei^age^eiit : tn . . 
5 order to make a secondary operating system Miy p^cjii/pUifeJe.;^ seeqiVdajy. 
kernel ported to the nanokernel afeMtegturaao mp*?^ tit 
processor level but rather uses a software incer^^ • 
provided by the nanokernel (i.e., virtual exceptio^** ^ ore 1 ■; 
directly processed by such a secondary kernel, btit rafter rheyiire intercepted 
10 by the nanokernel, forwarded to the primary; kfcflaef ajnid only; ;th&£ pptioifaUy ; 
processed by the secondary, kernel in a;defenfed;way. \ ;^ 
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Initialization ' ' *'* \ ' { 

The nanokemel installs the-se^ndatfy ; 

time together with primary banks. On ; the other haiid, the Bnb| £etHi^imio«-o( 
5 a secondary kernel, in particular the kernel context $<UOp,-. U deJ^rt^rf th$: 

post initialization phase. . ^ 

At this phase* the nanokemel Mocates mcrciaty to iccep a ci>£y of- . • . 
secondary memory banks. Such a copy is. then usc^tb}rest^ Wg? 
1 0 of secondary system at restart time.; The secondary s^m res^:U\"tiOW©vw 
optional and it might be disabled in order to reduce th$ physteaj raembry 
consumption. 

Analogous to the! primary kernel, the .imiifekerjafci initi^ie.s thc.mal 
15 GDT and IDT as well as the initial TSS located; in tlws JuddeA ;p«*t-^ifhe 
kernel context (see Figure 13). % 

Similarly to the primary red ODT, fti^ i<iMar ^kmdH^lre^ -OOT *bas> 
two valid entries. specifying the nanokemel c;od£^ 
20 selectors for the nanokemel code and data ace assigned by the h&iiokerntfl 

interface to Ox 10 and 0x18 respectively. In addition, tfie secdftd^ryireal GJJt 
contains descriptors specifying the nanokeriqel ?$$d$ft sttiicrctirey used by the 
nanokemel tasks. Such nanokemel tables ath used to intercept seic&ndary 



exceptions as described to the nextsecttdn^TheinarookfOTwitSS descriptor* ■, 
are located at the end of the real GDT: 

In the teal IDT, the nanokemei instaiis taskgates to'ordef fe intercept ; 
hardware interrupts and nanokernel traps, to order fo hgrabftfriq handle a rajah 
exception at secondary totalization time, all otH^ exceptlons are also ■■ 
temporarily intercepted by the nanokernel until •» nati ve. IDT ms&led-via tfi£ .'• 
lidt nanokernel trap. If such an outstanding (fa^) ^c^io^^ccws, t&e 
nanokernel simply halts the secondary kernel bit it disturbs=neither. primary, .: 
nor other secondary systems. Once a native Ipi;is to«iMle$ the writiatfy i&tti 
fatal exception gates are overridden by the native ones: Note however tiaat it ; ! ' 
does not concerns the permanently mtercepted exefcpitoni described to die . 
next section. 

The nanokernel launches a secondary kernel- execirt |hg a ta^k switch, to 
the initial TSS located in the secondly kernel ^n&xt.:.Piguie 14 shows, how 
an initial TSS is initialized prior to the task s Wishing. Note-ithat ofijy nc>n ze^i 
fields are shown on the picture while aU'.2ei»:>&tos 'am.shadWed.- 

Analogous to the primary kernej, the kernei. content physical address is 
passed on the %esi register. On the otliet tiand^nlike die primary k^;nei, tiW 
interrupt flag (IF) is set in the processor. flags field (EF'XAGS) enabling 
processor interrupts even during the sectinda^ ikePtiel t&tUrtiftatifcn ptiase. ft ■ 
should be noted that even the secondary kdrael toitwuixaviori.code^ fully 



preomptable by the primary system. .This is ; pttftjbtt^ Mpo^iUPta wtor ix> 
do not disturb the primary operating? systei^wliBjatia fcfccoivdttt^ oggmtixjg 



system is restarted. 



■ i. 
i 



Despite of enabled hardware: mterrupisj. tfcjj- few* exee^ijhp • I 
(corresponding to hardware interrupb) are disabled wb^n-aig^Ondary fceinel- 
is started. So, interrupts are not delivered by the n^nci&cmei liWd^sV are : 
explicitly enabled by the kernel at the end ot the ^iiii'inj.u|ii4^ioia ■ 
The software interrupts masking mechanism (bastftf tin. Virtual e^pfions.V i& 
described in detail further in th«s docujroait. . .:• 

The CR3 field points to a one-tor'o'ne,traiM^dR :.twe..' jscch .ah iijkklf 
one-to-one mapping is temporarily prodded to a sis^wfaiy^efhoV Note tiiaii : 
this mapping should not be modifie^or pe^ahe% U^d b^th^:4ii4^atiwf : 
code,, instead, the secondary kernel ihould build its awn & v" roapptiig and: ' 
switch to it as soon as possible. .. <■■' .<••':'• 

... t" • ....*' 

• . , *•*•".* *!••*"■**" 

The stack pointer is invalid wheiji. a secondary, k-enjeffe s^titdd! V 
Usually, the secondary kernels 4 statfc mijrtai sij&fc locatdd in tfec data * •• 
section in order to execute its ^initialization coVl/e. ? .1- 

Analogous to the pidnfciy keN^/du^£ u>e li^fi^s!atoi*as^ a ',* " 
secondary kernel typically invokes tite nanokeraet^in oijdei^ ihe. . 
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GDT, IDT jpd task registers: Firi^ tte , . 




In order to intercept a seco'i|da^^ 
task gate to the corresponding entry of the'reakDjT fft^i whfan «;ucl!t a^ . . 
exception occurs, the IA-32 Intel processor perjfwSfts a^k • switch which 
saves the processor state to the current task state ^grtieoit (TSsVftnjd restore 
the processor state from the TSS specified byilhefexceptipn tak^aie. ';. 

. . . ,.* • ' < 

For each intercepted exception, the:na$oie^df: ^at«^ia<fe^a^<i 
TSS data stroctute pointed out tya dedic^^^^ ^ 
the real GDT. Such nanokemel segments Ku^.t^iefeaaiw the'nanoRc*^ 
TSS data structures) are located at the end df tji» real <3I5T. Aji laariokertwl 
TSS data structures are similarly :iniuaU«ed «c^ t^ihe iwnol^el 
execution environment Figure 15 shows .n<m*ew*fi^ 
The zeroed part of the TSS data structure is sliaddwed-pn : : 'the lligute.; 

The EIP field contains address of^^aiofe^^^^^ • : 

EBX field points to an exception descriptive :' • 

exceptions can be multipiexed in the same iiaedl^iW'exic^ptiojvtaak. Far 
example, the same task is used to ^o^^ili^a^^termp^.:^ this 
case, such a multiplexed task can use tto-exc^itiri dWcrjptoi (ayarlah# on 
the %ebx register) in order to obtain an exdep^pa specifii infom^jv . 



All intercepted exceptions cm be ciassffieit Riding to : irs : rratwte;aS: . , 
interrupts, traps and programming exceptions r <tM ite & : . 

The nanokemel intercepts all hardware ijiitf^pW.Unoj:nding ; .che rtuyi : 
maskable interrupt (NM1)) in order to forward hisiti ttith* primary Jcempl. 

Traps intercepted by the nanokemel are 4 «irif m; tbe : featuring- \ " : : ' 
nanokernd invocations: . ; : 

O&generic trap 

, ©XIRQtrap ' ';■ ; : 

dbSTItrap ! .Lj ; : • 

©IRETtrap ! v : 

The generic trap combines all npo-perfbjsi&irafc^ 
invocations like console I/O, Igdt/sgdt, i^u%i : to», •*eb^t, -risstart. Tnie-; 
nanokemel method number and arguments are i^^>on.;'gerteiral pwppi^ ; 
registers as for a conventional crap^Tbe '^i^c^^KU^^I^Pf^^' ^ ^^c»ir^!»«». 
exception task which invokes nahokernei methods ^ccoitiing to m number 
coded in the %eax register. 

Other three traps are performance tirHiOjt aft&they ;^fe handled by 
specific nanokemel tasks. Thesehraps h^ye nt>;%-^m«ieMS; : : ; 



The XIRQ trap sends a cioss. roterEijpit: to',% |fe^^aqies|i^p.'-. •: : 
XIRQ trap task is equivalent to the.tet^crup.Cjtoj5k ' '^^'i^^-t^^ib^ ". J 
forwarded to the primary kernel cdrtes^asltD^ . it^o^f^ %a£t^4- ■ • 

than to a hardware one. So, like an jtaterrjjpti^jje ^^^>t^^s^a^^^---.. : *l 
current secondary kernel. ■'".•*;'. '"':'.■} ' • 

•■: \. ! .. : "!'.••■'" :.' ,"■ v' 1 

The STI and IRET traps isdto-o^M : ¥y*i^^^k^^| W'<rjtf^fe' 
process pending virtual: ex^ptk^.-Jftt^j^ 

interrupts masking mechanism and. the* : kp6thMQph *Uta&U-$)iib n'e*W = • 
section dedicated to the virtual ebtc&pdohs; , • \: . . ■ :• 

Analogous to the primary Ite^^^i^jB^ ti&ii&jfr poes jfctf 
intercept programming exceptions except soi^i^'^ 



Thenanokemel intercepts the folfc^ 
emulation: • / ' V - j" ••' "' ' V 

©.the invalid opcodeexcepti^n #lJ^i^-y • : : . : .. '• 
©the device not available excep45^.<^fe ' 
The FPU emulation feature :£s oi^S$'t|j£ ;|^^^^io^iemejit ii- ' 
lazy mechanism of FPU sharmgWd^aeribed.fa&^ ? . ; 
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secondary operating system, In «c*se, the drffctpni toaq^iy^tcepb 
some synchronous exceptions related either to ^k^^m^H^^^ 
instruction trace) or to program entors (e.g.., page-^lji S^hidehMg agimt 
design however is out of scope of this document. , . 



' • : ' 



' - ' " >' 



•: - J 

■ 3 • t 



■: * ■ i 



Virtual Exceptions • . 

Virtual exceptions (VEX) is aniechonifetn $miidjsdby:dfi feanoitefipi ..- • 
which allows a kernel to post an excejptiah to a secon^ar/kfek^ afl*(b •' ; .'. 
deliver it in a deferred manner. In partiphlar, ihe.V&'^ebh^iijiar l ;is:use.d in vi 
the IA-32 Intel nanokernel architecture in order to Beptace liardiare fernpts. i 
with software ones for a secondary kernel. 

■:' '. .' ' ' ■ ••' •' : 

The VEX interface consists iritwo fi^^^ \S, 
pending and enabled. These fields are meani^ftiion^ for ti ^o^y ^^i ■ j 

virtual exceptions are naturally enumerated by:*he hl^tirailn Spending , ; 
(or enabled) field. So, there are in total 32 vim Ia i'texcfepd^i> sappcirted : by : the ■■: 
nanokernel on the TA-32 Intel architecture (theV^^and ^WSeWs-are 
32 bit integer values). " " . : .' •*' 



The table below shows hoW die virtiiaii^ceptfdn^ a^rn&ppect to the 
real ones: ' •' : 



Virtual exceptions from 0 upto l^a^.raappad to 1 ^ hardware : ; . % '.: 
interrupts. The virtual exception 17 is m^i^m^^^^^^^ ■ 
deliver cross interrupts to the secondary kerneiL T^.viiu*a> exceptions frcsn ; : . 
18 up to 30 are not currently used and ttiey, are reserved *ftf^TO*xwndW 
The virtual exception 31 does not cx>rces : pprid.; : to any;,K«d ^feption and tris i*: 
fact a pseudo virtual exception which is used mfef Jf riy feyShe timo^m&W ' = • • 
order to detect whether the kernel is idle.- How such .?( pseMtfsvjrtuai . '■ 
exception works is described mo^^^ [ ' ' ' ,\ - ■ . ' ' \. 

Because multiple virtual: exceptipns^^^^ . [ '■ 

but only one of them can be processed at time, alii v^^^jji.cepflotjs %e ;• 
prioritized according to its number. The highest pruilty »#ig^I 
NMI and the lowest priority is assigned; to the FLunnlogp^dp es^ptionv : 

The pending VEX field of ; *secoMary^»tex^ is xypi^afty itpdace^by '. 
the primary kernel which provides a* driver far 4rtt«ff PtC debtee. Sucfo 
driver usually posts virmalexceptiohs'dntWiup^ 
setting appropriate bits in the pending VEX field: : ? 



The enabled VEX field *'s updated by ^fe w^^^:^ Drd fc r to 
enable or disable virtual exceptions. A^ivei Vtoiili^pii^Qii, mtB^ if 
the corresponding bit is set in the e^Ied'\mM*Mj^'ite maMed^BX 
field, a secondary kernel implements criUcalrsecti^ns.ptoteeteid against 
interrupts. In other words, a secondary Wief inore uses Qfc 'ci, ^sti A- 
32 instructions to disable/enable processor. ^t^pfe bui rather hiodiiSes the. 
enabled VEX field of its kernel context, ; 

A given virtual exception is deli vered ; by &e!^i»l?emei & ft: is ; 
pending and enabled simultaneously. iTitfiwdU^ 
pending bit just before jumping to the secondary tow^^^d^ '•' 

When delivering a virtual exception to a sec^cy^neljfe: :• ' 
nanokernel interprets the gate descriptor ^.ij^ife jfrfca, order to 
minimize modifications in iow^evel &andiei**r> s^diry 
nanokernel calls the gate handfcrin the sarnestafts ai^^a^^^ 
does. In other words, the nanokernel swi^a IjN-s^pj^fer; ^ 
stack segments and pushes me^ception.fra^io^.^ W^is^ Wack in the 
same way as the IA-32 Intel hardwaie^does: 



' 5 ' 



Note however that, when porting as^ndary.^^^tk : iA42' 
nanokernel architecture, low-level exceptionrhandieTS have Lift to he 
modified in order to take into aceo»nt:the.s0iWa^ . 



mechanism wmchsubstimte^^ " V 

gate handler, me nanbke^^ 

0x80000000 to the enabled fieii Theh^^mi^^ ^ 
atpmc^ssor level whenrunnmg*^^ 
Kernel can be preempted by the pr^ary ^ 

gate handler/hi such a way, mi the na»0kernel>e»^ : T . 

operating system becomes foEy preempt 

A virtual exception can.be posted by the; frintoy^jei ^Jsim \ 
disabled state. It this case, the exce^n'^^fi^^dj^-tis? aejSd£^| : I 
kernel but it is ratherTeept pending until me e^ti^s;^'e?f^4^«j 
when virtual exceptions are Enabled by iai^nch^y^el; a^^si^^d; 
be made whether any virtual exceptipifc 
the secondary kernel should invoke, the nanokfemel.^ 
pending virtual exceptions. Such mvow&oi$i*p^^^ 
STI or IRE? trap. • 'J : .' 

^general, a secondary kernel^ 



following cases: ■• '.- \ 

©when virraal exceptions h;^^^ . 

secondary kernel m wderWp^ : 

©when virtual exceptions, has; be^ disjibied : by tr,e n^dk^rM aa 

msult of an interrupt gate invoca'fion; '>..' 



In the former case, the secprtdary'ke^pKu^es. t!to«:STT fafif&p&etb . ■ 
pending virtual exceptions if anyi Or^'p&^big^^^^ 
nanokerael will return from the STT trap in 
kernel execution. 
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In the latter case, the secondary Ji^lii^ j^RBT^g prb^fcs • 
pending virtual exceptions when returning h^?^^b^li|UrJI^ 
that the 1RET trap just substitutesthe iret lA^lin^tMin ^d'^^l^iap 
is executed the exception frame is stillpiisMjittt).^ jupertfspfiijapfc.. Note 
also that the nanokerael does not return tW^liwW* Instea^U^ • ' 
pending exceptions are processed, the seccttid&rjt operakng syMern ^eeulik>.n 
is continued at the point it has been pree W ed;% fbe; initial virtual ;^ej4>ji .'• 
In other words, the IRET trap rethrns. to the stat^av^n. die-es^tion ^xxm 
located at the top of stack at trap time. 



Nanokernel Re-Entrance 

The nanokernel code is mostly eixecu^?^ ife&abtebiaij : ) 

processor level preventing re~ehtrance into th^ i^^&^fi&h Cfiifhp otKe^^^ii, s 
some nanokernel invocations may take alongti^ \ 
nanokernel has to enable intemipts when exeOTtji^ m; \ 

order to keep the primary intemipt ktencylow. ; : . , < 

• i * . ■ " * • 

There are tree kinds ohong n^ake*hel bpftp^tida^: . 

Synchronous console. output \. ' . +: 1/ 
The operation duration depends on di&^o^4i^'SpQec^ ewu^fe* ; 
on a 9600 baud rate line, a single character output j-ifeay ^p.td ^ V ./ ■ 
millisecond. ; . : 

<B>lgdt and l\dt . y. : - ' 

The operation duration depends on &e fti^c 

operations can still be done with di^ledi^^ for the priidi^y Kpniel 

• . . . *".***"•.•*. ■ 

because they are typically issued at injfcializ&ii^ i^fcarrapt^:^ 
usually disabled anyway. For the secondary however,- \i 

is clearly not acceptable to keep interuiptsdka^ a secsondkry . 

* ■*. ■ '. * ■ • * 

kernel can be restarted at any time* : ' 

dpsecondary kernel restart . ' 

* * .* ".".*•• 

The operation, duration depends on ^e^flftbl ii^ge; tifrfa win^his • 

restored from a copy. 



For all operations listed above, the nAh^&eli fables ih^mvp^k«4 ; 
therefore re^ntrance torn the primary kernel ipiffb^^ haad, while:- 
interrupts are enabled, the nanokernel scheduler ^icii^Hled miordcrifo ^prevent 
another secondary kernel to be teheduted wl^ fro»'tb*>ri^y 
interrupt handler. Jh other words, the : nim6k^J^„^ preempted by the. J ' 
primary kernel only (as result of an inte^ptjcpulld^fettbe fejrti a - 
secondary kernel is prohibited. Such a rest,^*^ 
global resources for the secondfcr/c^ 

data structures used for ima^'a^y^^^ ^ ^hared acKoss^ 
secondary kernels. I ' ' 

Some long operations issued from a seeogli^ feernol ear, be keeifted^ 
in the primary memory context fo omer wor§ s b|feixd C u^ s.uch'.m ' " ' . ■ ' 1 
operation, the nanokernel switches to me pri^^^:^^ : 
enables interrupts. Once the operation *?*fcfej t^^^eJa^s ' " ; 
interrupts and returns to the caller Sec6nda^^l:& u ghi n^oker^l V 
scheduler.. . ' • 

* * • • i * j * 1 ' 

*■■*.'-. • • V i ■ ■ * 

* ote however mat somteloi^^ 
Primary memory context b*c^^ " • -j. 

located in the secondary KV mapping lA^^^^^^^^; ' 
are secondary Igdt and lidt n^odVWh^^^ mtTsdMk 
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structures respectively,. So, these operations jniist ;be 4ai?e in the hario k&m$ 
memory context. ! 

• . - • ' "■ : . " " . ■ j • . 

Note also that it is preferable to execute freqq&iA^; 

5 methods in the nanokemel memory content Cejveii if ihay - 

the primary memory context as well) in dxti&r* o avoid lin m lovcirbead 

introduced by the switch to/from the.pnmaiy fexebirtlonjeiWirormiertP k [ 

typical example of such a frequent operation fe u Kj^cj^O0!O^6iAptit-*oa tHjifev 

■ ; ."••*■ . 

nanokernel console. 

10 ' : - • " ■ .*•:-. .. 

The discussion above shows that the riWofceme^ must bfe^pdWe fo£ • . 
enable processor interrupts while executing cpd& lt£^ 
context with activated secondary GDT arid IEi>T. in pU&i? wkrds,the . 
nanokernel must support a task switch to the inWrr^pt- titsk wliile running: ijhe . 
15 trap task executing a secondary nanokernei method.*; :. 

• • , ... 

• . . . • . 4 • 

In order to support such a tasks nestu^g, the ^nofeeEnfiJlihVii^l3iefl='a : ' pari 
kernel TSS stack located in the hidden; part g£ the ftepiel Context as sfotoWi.au- 

• . « > , ; * * • * • j 

Figure 13. This data structure are meaningful^ ly for % secbncbury keroel : ; 
20 context. The top of stack points to the current TSX'jUe.i lo the TSS'pbmtejl out 
by the task register. The stack i» updated eacn:titvie ktask switch i» fje&g^nei). 
to/from the secondary kernel. When anariokemel t$sk : its activated fcy a t$»s3« . 
gate, the task TSS is pushed into the stack. When tjte nattbke'friel retires- from 



a nanokernel task, the top TSS is removed from the ^efei^e.-^ ■St^cfe.ii : [ 
also updated by the secondary! Itr method- w^^ ^j^^y/ 
TSS located at the stack bottom. ' • ! • . : : ' . 

." "' ;.' . ■; :'■ . ;••!•; .." 

Figure 16 shows typical states of a Wii^jiHi 
figure depicts the TSS stack evaluation wK&j S^o^a^feeth^^'p^^t^!^ 
by an interrupt. The bottom ^^^^^^^^^^^^^ 
when the nanokernel executing along secona^y o^^n is 
interrupt. Note that the TSS stack ^^^/^im^ij^ n«* 4pth; 
is limited up to three.- . . 

A native TSS is always located at ^^b^^^^^^.l . 
by the native secondary kernel execution" «&ir^ 
above, a secondary kernel, is *ai1^us^^ 

part of the kernel context. During the initiation: p^jj secondary ke^i •. 
typically installs its own native TSS usmg^ltr^ano^rnei i^^-SuliV'j': ■ 
native TSS overrides the initial one in the tbg stisk;-.- ; /' ' 

Once a secondary kernel U ^^^^^^^ 
method is invoked via t^ i 
the task gate. The nanokernel H&fcii^ |^i^r' ^ ns pwa4s|itb ! 
the stack, m the case of internets* Wi^^^^itasfc^S^: • • ':' 
switches to theprimary kernel in ' ^tc^^^r^^^^ ea ^ b| ■ : 



crap, the nanokemel may enabfe totenupta whjle ex^utingcadje i>£ 'it; fang 
method. • ;; j- ' 

When interrupts are enabled^a nanokeihtel iriptftad* can be ^<n^|5(i?d.. 
by the nanokemel interrupt task activated by a taafc \mc:im$.ti$ interilapt .ta^" 
in turn, switches to the primary kernel in cirderfo pijocess tht infeo^pl. Once 
the interrupt is processed, the primary k^ckretwnjs to jfte tjapoJcftiiipUn 
order to resume execution of the interrupted melttoii; -. 

Because the trap and iatenrujit tasks ctfti be* toekecl, it is fijp^^aa-y to 
use different (non overlapped) atacids .wijen;eXecuyjEig tha takfc cod<^ The 
nanokemel uses a special interrupt stacfc-inthe : int^tr^t task. .} 

■ ' . ■ *;"*•• ' ! . - 

When an interrupt occurs ik* the trap tflsfo t$<* ixot^sxir swkuht® to tffe 
interrupt task and saves the general -purpose rdgist^ TS5 ; 

(which is the current TSS at this mdra&trt)! tkvts, dbce iritaavpts to^: di^afect , 
again in the trap task, it is necessary to re^inidaii4 : d^ i BSt» EBX:a&d KS**- 
fields of the trap TSS because they botUd be corro^ted by an fatemipti 
Scheduler 

The main role of an operating system J <sche#lei:i$ t«>. choose Xhe nex t 
task to run. Because the nfmok»rhefrc^ 

the nanokemel scheduler chooses? the next:S<^ond%y qp^rattog -ftykjierr! to rim. 
In other words, the nanokemel adds an extra^pfe^ttliiig leve^ to ife«* 1 wlu>Je 
system. 
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Note that, in the nataokemel'arohitoto 
has a higher priority level with respect, to srtcdnda^^^h&^it^^u,^ ' 
given to a secondary system only when : we:;p*m^ 

can say that the primary kernel is not piieempfcablp erid il e^lic$y Ijiyokfcj ••"* 
the nanokernel scheduler through the idle n&hWcaljeJio <& iifrfyfo m^l 
an interrupt occurs when running a secondary primly kernel, 

interrupt handler is invoked. From the primal kerpel J&qtftfg w r %h.'ai. 
interrupt preempts the. background thread e^«^g !- } 
interrupt is handled and aU related tasks- a^d^rhep^ ; 
to the nanokernel which invokes the. nanokomel ^hedtfler - in prdeii ite " • : 
determine the next secondary system' to' rW j»icun-the^^'p,k^rv«i- • 
the kernel just returns to the background th^^^^^;^;^ i^ m ^ : ; 

The secondary activity is transparent for die prinwy 
15 change the primary system behavior. 



The nanokernel inay implemeM d^ 

default, however, a priority based algorithm i c ' : 

priority level, the nanokernel uses a «»iid4^:^te^^ potfcyj.Woriiyi&f . 

a given secondary kernel is statically (*iifig^^.«t^fem Wgft biifld tfe ' :' 



20 



Whatever the scheduling policy i& implemented me texhjfcr has ;to • • 
detect whether a given secondary, system Ls.ready Co run. This condition W 
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calculated as the bitwise logical afcd op^atfdn awl 
enabled VEX fields of the kernel context. A nifo/zeta j^fjjt 'ihdio^s.that the 
system is ready to run. 

5 As was described above, each bit in tb'e. /^fi'mi^g: ^Ipf -atvA erteihled; • 

VEST pair represents a virtual exceptrbn. Rephi^iftg the ?€$dy : ib JCtfl? Qrt&pia; - 
we can say that a secondary system is in the ix^^'.to.^'-^t«-f^tbi^ is ai 
least one non masked pending virtual exception. • 

10 Among all virtual exceptions which arc typ'icaijy mapped tdit|je 

hardware and software (cross), interrupts, there is! "ft apepiak virtual ^kcepti^n = 
(running) reflecting whether the kernel is currently idkv. " * < 

; ■ . w * . i . . . : 
The running bit is cleared; in the 'pend(ng:&&^ \ 
15 secondary kernel invokes the idle method 'm^j&^/wM^hit i'teswSf in ^Im- 
pending VEST field each time a virtual exception i& 

kernel* " J-., y"" \ ' \ " 

The running bit is noxit>aily always sefi^^ >for a i v 

20 running secondary kernel. The nanokerael se^ iftis bft vjrtien it aecmntfary 

kernel is started and it resets tiiis bit when, n $ectfif dmy -terhel is hi) ted; The 
secondary kernel should never clear th^'rtmnitig ^ 
interrupts mapped to virtual exceptions., 



Note that an external agent ii abl$ fo-aitsppt^/^ W^eai&«» di'ia. . 

secondary kernel by clearingftestoriiig 1b& enabled)^ kernel » ! 

context. This feature opens pbsslbiiities fdr a isched^iing. policy Si^f:to bS} ■ .; 

implemented outside ofthenandkertiel.ias a ; pr)m^,jks^i:task. ^iaditiott-H 

this also enables a debug agent for asecoridary^emet to toe ruiinin^ as 

on top of the primary kernel. An advantage oV^u^U^^^dSirydebiig %&nt; ? 

is that all services provided by the primary o^erati^g'sysiem become- amiable; 

for debugging (e.g., networking stack) and the secondary kernel debugging • 

may be done concurrently with critical ta*jks rann^ 

system. . -.' 

Cross Interrupts . • "\ . i 

This section mostly consQH<3at^ given hi : 

previous sections) related to the -nanokerael crass i«n^x^i|As- ttieetia«risnf 

A .* ' • * * * * * * • . ' ' . * 

• .■*.■•'•".*« ' ' ' i 

••- ■■■ . •> • '•• . '•' ,:> .} . '• ' ■• ' 

Two following kinds of cross interrupt wi|I fee considered here: • : 
. . ea cross, interrupt sent to a secondary- kemfei. '. : ' : • 

■ ■ 1 * * . "" * 

©a cross interrupt sent to,ihe.jprh^ 

... ■' ■: - : . ; : •' 

In order to send across iti^pr&fcd^lat^^ a : • 

source kernel first sets a bit corresponding to IheeMs &rrupt spurceinihe: 
pending XIRQ field of the destination • ' • \ 
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kernel context. Then the source kemel;P*l# m jjfc&I^W *! ; [ 
the destination kernel setting the cowespbn4^^^p»^^ 
of the destination kernel context. Once tlie 'c&ss; jj|l^«#l**i^*»«^SJ^t : j ■ 
the nanokernel, it checks the pendi^m ^|l^&^P«^:«Pi : ] | 
the pending cross interrupt source and fiiiiuly Wv'^h^iers atefe* t^ft*. 
source. Both source and destination:kera?ls ^^oi^Jiwttwl^Jp d 
thep^mg XI/?Q field. Note that the same aig^miifrOTeaby^oth ^peW. ; 
source kernel: primary and secondary. j" " ; * " : 



10 In order to send a cross interrupt to the gr^aey/.^row^a 

kernel first sets a bit corresponding to *e cr^n^pfs^urce ^^jum^rj 

X1RQ field of the primary kernel context; Th«^^^^>%»f invofc ■[ :. 

. ..... 4 j -. : . ■ i : *. • *.*.'. 

the nanokernel executing the XIRQ trap : Tb^na#kei>#l. iinffledfotertf 
preempts the secondary kernel and invokes ^^;i^<ip^rleve^W«J; 
1 5 interrupt handler which checks the pending JC^I^^wiaj , ; • : . : ; : 
corresponding to the pending crosa interrrtpt sousee 'afcd#n.*Uy. ^v^tes 



i 



handlers attached to this source. / 

• •' ' ' .V'.'" ' : 'v j • • : 

• . ' . "j ....... ;•' 

The cross interrupt zero ranstinotlbe usediW^ 1 ^ TW latoP 6 « : 
reserved for the nanokernel to nbt%.keme)s >ihat:|a baited feemel-btts been: . 
started or a running kernel has beeTOri&fe i^yfa*in$m ittteirupt; 



It is broad casted to all running kerri.efe eaefc iim^thfr tf&agfhpytivt^^etf' 
is changed in a kernel context, , • , 

FPU Management !*:. ."' •.' 

The FPU engine is a computing res6tir<^-^ig^ : is cypi^i^'sJ 
all operating systems running in the nanofeerAei^t^ncfn^ient. ' • 

* 1 • • ■ 

On IA-32 Intel architecture, the amudoaj^ 
in a lazy manner. This mean* that whefc a swjtd^^^o^ati^ «y«h^t^ 
another occurs, the FPU engine is not. immediacy ■■give* ta the newly i: 
scheduled operating system instead, the FPU^itefc iMcferrediukil the tti»" : - ; ■ 
newly scheduled system really executes floatmj^ra( j^am^b^-^id )■ , ! | 
accesses floating-point registers. . '-• •! 

! - • 5 

• • . - : , : : •■ : : U 

Such a lasyFPU dispatching.algorithm aUA^.srttjelnano^Enel ro = 

reduce the system switch time. This as especMjy jnijsoiant 'in bjtfer.to fediiee ij 

the primary interrupt latency because FPU is .n'ormi&iiy ni* used at brt$m»pf ■ « . 

level and therefore it is usually not necessary tdlsave ajiidi-estot'e FPU 

registers in order to preempt ^secondary operat^ system and ro-<rtt|l u • ; • 

primary interrupt handler. ■; ; 5 

. The nanokernel handles an FPU.b^V^^tv^kbfe.j»n&Wto the- 1 i 
context of the kernel which currently uses^ui%&^^ei^Ms-W> J jPpu' • = 
owner, the FPU owner context is set to zero: An : FPU context islo^ted In &e 



hidden part of the kernel context. Suchla conste** kee^s state, off the FPU 
engine (i.e., floating-point registers a^st^s^^'^^^'^^^^V.'* 
owner. Obviously, the state of the FPU bwnef is Jt«pt by {he 'PPO #gi^ ; i' : 
hardware. When the nanokerael changes th^FPtf- owrie*, *e' : JFP?J stas is ' ', 
saved to the old FPU context and lestoiqedTrom^henewone. : / 

• . ■. • • • • • : * *■**.:» 

The nanokemel uses tte ; emvaaabnbil.i^MHf ^eCfio ^istef Ik " : 
order to provoke an exception when FPU is nsitsd .bv a ^n 'FPU owner; Tbfc ; 
CRO register image takes apart in the hidden pltit of ■ttte kwned cmtexl^W ;; 
CRO register is saved (to the old context and :r^tptefi (from thciwsw wjnte)pt) 
at system switch. The EM bit is set in a£l keroetc<3ritesis i^reptthsFPU 
owner where it is cleared.' In addition, the nanojeniei i^teccepts^hiK invalid : - 
opcode (#UD) and the device not available, (#E$M) exceptions- for all npn 
owners while the FPU owner handles these e^ceptipas in active way; 

An. FPU switch occurs When' the; nanok^rneT tntei^pt* one FIR® 
related exceptions: #UD or#NM! In order toswiteb ^^ : FFU:»ngirt^tvve«MV 
two kernels, the nanokemel releases the currenfFFtt ownelr and -'assigna the 
new one. : ;\ .• ■ - 

In order to release the eurrenfcF^ a^ojtepc^ sav^vtjKe/ 

current FPU state in the kei*fe* context*nd-sefe 



image. In addition, the ^ofa^ga^'^-^t^liii^e i^^^o^r-' 
to intercept the #UD and #Nlw( e^piiom. ' _ j'. .. 

In order to assign a new. FPU owner, the «a*6l&ni<5f i^tor<& • 
state from the kernel content and dears te^f'foti^ <&'^M fa , ' 
addition, the native. gates are installed in <foM j ltyj|*r order *o j&jfc j& 
#UD and#NM exceptions in a native way w^pw^ng^li;- 



The nanokernel uses the OSFXSR bitf of *hei 
optimize the saying and restoring operations'^ tf^j '. : 

part in the hidden part of the kerhei:context.i i* Sft ^j (U) ^ tf^tkt) , • 
and restored (from, the new context) at system s^tcli TneVn^oke^lMeUb^ 
CR4 register image in order to determine whjn^c&f ' 5 

be saved or restored: standard or extended. ltis;^fe O^vl^MtU^' \ 
not save/restore the extended FPU context m ^^^g^^mch pfatf 
neither MMX nor SIMD features. . . \; ! - 

Because the nanokernel iase* :the :uf ih4 K*g>ii in ohfcr. to4 

implement a lazy FPU switch ja^el'ris, hottallo^ to chaise tl^ gca'iw : 
this bit In particular.this n^ui^&f^^^ is^fr^p^ifi^ a : ' 
kernel ported to the nanokernel toehitecniie: 



Note that usually an operating systBOT ic^H^ tfc&TS^M 
CRO register in order to implement*^ , 
Because the CRO register image latest pkt iitfthevfce^ context and : ' 
therefore it is saved and restored at system swifch^itfee oative^j- ; : ':• 

management can be kept almost unhanged hi ^ 

u ■ • : : • " 

Note however that the TS bit'lSmtoH^ca]^Wby a^WitcbV/ 
This means that FPU exceptions can occur in a secondary fc^atfenif ft^- 
bit is logically cleared from the kernel potnr of viejv- -Such spurious FPU- 
exceptions are introduced by task gates used by ^BM^M^^ to • 
intercept secondary exceptions. In order to detgct s^i spurious! FPU ;; : 
exceptions and quietly ignore them jUu* cleakng ;.t4isib&), a i^eOfidary 
kernel should handle a software copy of the TS bife^-«iw6^^'^}^>d:; 
secondary kernel in this task providing afjelddedifcjtfec^^^ 
kernel context. \ 



Other aspects and embodiments 

• *" • . * . : ' * * * 

It will be- clear frOm-lhe -i^^s^ttecli 
embodiments are only examples, .and! tt^ 

possible. The operating systems, platforms and: '^^mig te^^ am {: 
mentioned may allbe freely varied. Any other 4odiilcation«; «Ub>m.iflSoiiJ5.! 
and variants which would be apparent to rhevskitfcd -persiw. >e tcj be';, 
considered within the scope of the invention, whether or not ^^:by tW= 
which follow. For the avoidance of doubt, protection is sought for! any 



claims '.. :•; '••y.- ;/ ; • 

1. A method of enabling ttimfr- di«^i^^ ^ 

• ' ' . •" .. ' s,- ' '■■ '■ ■'• : : . .. • ' ■> 
concurrently on the same computer, comprising*' .;,;•.-> ;• j 

selecting a first operating system to ftave;^]^^^^^^ 

selecting at least one seeond Dper^^iisfci^-.tq^ have : a jdAWefr 

lower priority, ' •. \. ; 

providing a common progtatn rim^i.-fr ij^k-bew*» .«a»"- ! r 



providing modifications to said first attd .siaooi^.Q^vari^^ systems to. } 
10 allow mem to be controlled by said common .p*o^m.-;> 

2. The method of claim 1, i» which the -tot^^fe** Wm-fe;.*^: •'; 
time operating system. \\ -.. 

15 3. The method of claim 1, in which me sWi^-'^J^^^y*^?*' ; 
real time, general-purpose operating system. 

4. The method of claim. 1, in which- ■^_^ii^^^^■y^ 
Linux, or a version or. variant thereof.. - : : ! '•; 



20 



..>■ ' 1 



5. The method of claim I, in which the cottlriwiw* 
save, and to restore from a saved:^fsienV ^^^'^ lt > 
switch between the operating systems. ' • • ' 



6. The method of claim 1, in. Which ^e^ogi^^^' ttW ^coii: 
operating sysiem are handled m virtual f^hion by,^ common -^gmmC. •'• • 

5 7. The method of claim 1, in wMcb m <?;^^^ fc£ 
intercept some processor exceptions, and W^^m^^J^ 
of the firet operating system to service them. . i ! ■ 

8. The method of claim 7, in which the. pressor 

10 second operating system are notified; as : virtual lOtfepitaft*. ' | 

9. The method of claim 8, m wmch^com^p K 6^a«i kmdns^L^ t 
call an exception handling routine of Uhe' ^e6ond grating/ ' s^tom- 
corresponding to a said virtual exception, which is ipeWi^.. ' > • 

10. The method of claim l/italher compii% .prlti^^&^i 
operating systems with separate- memory daa: ": 
exclusively operate. 

20 1 1. The .method of claim 1, fiirther^ ^ of said': f 

operating systems with first i*W -a^'oi^ device* of suirf computer to; ' 
which each has exclusive access. ■ • 



12. The method of claim 11, in Whteh ea<^ ope^itvg afcee^* 
first input and/or output devices using; :^nmoif^d| ma^Vfc: 

routines. : 



- * t ' 



13. The method of claim I, further compiling ^ov»$. ^ :^:^ 
operating systems with access- to '-secodd- in^-4W^-i^t;ii^te^ 
computer to which each has shared access, ■ . 

14. The method of claim 13, in wfitch tit 4$kminz ^steii^^d^ • • 
second input and/or output devices using the nwmv* of the -ft*r flptt«^. 

system- : i\ 

• *• * 

15 . The method of claim 1 * further, comprising ipr^viding *' jfetyaq totR&&. 
for restarting a said second operating sySteres without; jnti?rnipti^ opbtttfofl 
of said first, or said common program. : 

• " '. • • *. * . 

• \ - ,. '* • ' * . > 

16. ' The method of claim 15, 'in -which the co^o»! : P^g.»in ffo*W« 

call mechanisms, to control the -.operation .of th> second r^Ttt^ngikyskiro|:- 
and/or event mechanisms to notify the ficst operating of statos fc$ofl$ 

in die second operating system. .J 



17. The method of claim 15, ia wfclch M odi>a^=progrkn *tore?> Bopjsr 
of the system image of the kernel of! Che second operating sy&ehyand.fc 



10 



IS 



20 



ranged to restore the kernel- of. the tecc^ j^^s.&y^'^ 
saved copy.- ! .1 f ... 



The method of claim 15, in which fi^an^Vjiioiia: -opiwi^. 
s have cooperating routines: to- enahiei ithi- first onbradne svc.Ui'i^ 



18. 

5 .systems nave cooperating routines: to enahie; .the-; first qpferat^g : syste^fc 
monitor the continued operation of the:seeondio^r^g..^wmi to tfio^tjU 
detection of a crash of the se<^d:cpei^ng'8y&]*-:' 



19. The method of claim 1 /further ;c«mpriimgpr6yidinfe 'i4^jjfa& 
in which the common program Is arranged' W oiiput tfee^tes of I kai^ - 
state variables on occurence of predefined coitions' m *he -^mkd^ ;pf^t, 
operating systems. " •:' . " : 

20. The method of claim 1, further comprj^ cdmoin^ ssk rip^nxg i 
systems and common program into a single code pfadnet: ; . ' L : . : : 

21. The method of claim ^ fWmer comprjin^ 

systems and common program 6nto pena^nt ^ n^mory ^ U a com^fe* .:• 
product. ; • • ' • 

22. The method of claim 1,' in wbiph^e ^^giptogrim si ad-aoged to ] 
provide an inter-operadng. sys^^ ; 



10 



15 



communications between said m^l^^^^^ 
applications running on thern^ ••-•!:• . ; ; 



23. The method of claim. 22, in . whiSh; 

virtual input and/or output devices Gb^pnd^glw ^e^^catidni^;^. 
bridges, so that said operating ^ys^i can.. :: ^c^^<a«e 
communications bus. j. l\ 




• •• • . : : - .f sL,.- • ... ■• 

24. The method of claim 23, in which .^'tte^\tjmfa*** 

systems comprises adding driver ron^fena^r ^ ;4^^<*jti*j 
devices- • t _. .v\!.' .-•/..".;.*. • 

25. A devel6pment kit 
performing the steps of claim 1 

26. A computer program-product comj^flg^^^b^ 

ciaim'20. • ■ '\?.V '.. \ \. ] 

27. , An embedded computer ^yAftp^ |^^|jl^Air »^fci^^-«ai*F^]3*«|^^ 
20 and input/output devices, having 4&® ^^jfc* -fo^ I 

programs embedded according ;to clalm>24^ : . . V ; ! 



28. A computer system comprising ^tvti^ j^m^ ' '^iixs imtf- 
input/output devices, having exe^ng-^^^^^.^^^ . ; 
a first operating system haVing.a itelatlvdjy hj^priGrity- . ". 
a second operating system having.a *cfe^^ 

a common program ^g^-/^l.^:.^i- ^h^^'^p,^. 
concurrently by switching between^ •••pp^ng ' 
predetermined conditions. . .:;'...«' 



29. A computer system according^ to- claim; *<?; jtm< fcajtf mt 

and second operating systems concurrency tfriijjg thef^KJd. 0^'af5iy 6f cktfrtij? ; 
It© 24. " ; • ' ! : 'i ' . • 



30. The method of claim l.'in 

provided with an idle routine, in which; iii^^l^bnWWie '^iamon i 
program. ! . . 

31. The method of claim 30; m^hl^^life^ttee ^jt^*^ ^ 
processor halt instruction. ! :': 



32. The system, product.or methoxj ^ ^|» fC Smg'cMm -fo which; the 1 
computer has a Complex Instruction Set.iufcT^eiiutei.; h 



Abstract !. ! ' * : 

A method of enabling multiple different op£l^^^ fonm^t^^rfflktly 
on the same computer, which is an Intel oMirtialar Cbinple^ 

5 Computer architecture, comprising selecting fii^" fel^K^I^^ syt&sftt ;tp 6oVi « 
relatively high priority (the «5aJtime.diperat|3g ; : ^i^riKic^-w <?5); Wcii^hg 
at least one secondary operating system to h&vea i^latwly iroWeipriomy^the: 
general purpose operating system, = such : ti^^ fe- jPtdv id irj^. a . ^cojtei^tm 
program (a hardware resource dispatcher sifetlap to a riwdk$t&^ imaged: to 

10 switch between said operating systems under precte^^^ conditiorr$;Umcl 
providing modifications to said Srst and ^9l>4'^ 
them to be controlled by said conmiqn progjf^itt^; *' ; • " 
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Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 
Q-FADED TEXT OR DRAWING 
□^BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

(BYLINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



